L Number 


Hits 


Search Text 


DB 


Time stamp 


1 


25 


((nic or (network adj2 (interface or adapter or controller))) same 
filterS 3) and ((frame or packet or cell) adj classif$8) 


TTCDAT- 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 




2 


74 


((mc or (network adj2 (interlace or adapter or controller))) same 
filter$3) and ((frame or packet or cell) same classif$8) 


T TCP AT- 
U or A 1 , 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBMJTDB 




3 


22 


(((nic or (network adj 2 (interface or adapter or controller))) same 
filter$3) and ((frame or packet or cell) same classif$8) ) and 
@ad<l 9981201 


T TCP AT- 
TT<3 PflPTTP.- 

Uo-rurUD, 
EPO; JPO; 
DERWENT; 
LbM i Da 


ZUUJ/U4/JU 12.40 


- 


2 


bandwidth adj broker$3 


USPAT; 


2001/09/22 18:52 






EPO; 

DERWENT; 

UoULK 




- 


22 


bandwidth same broker$3 


USPAT; 
EPO; 

DERWENT; 

T TC/"*tPP 
UaULK 


2001/09/22 18:56 




11936 


service near20 levelSl 


T TCP A T- 

EPO; 

DERWENT; 


2UU1/UV/22 ly.wj 


- 


3561 


tos or qos 


USPAT; 


2001/09/22 19:07 






EPO; 

DERWENT; 




- 


342 


(service near20 levelSl) and (tos or qos) 


USPAT; 
EPO; 

DERWENT; 

T TCi"V^D 

UoUCK 


2001/09/22 19:06 


- 


1 


(bandwidth same broker$3) and ((service near20 levelSl) and (tos or 
qos)) 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:06 


- 


2441 


tos 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:07 


- 


4 


tos same (service near20 levelSl) 


USPAT; 
EPO; 

DERWENT; 

t icnrD 
UoUCK 


2001/09/22 19:09 


- 


304 


(service near20 levelSl) same filter$3 


USPAT; 
EPO; 

DERWENT; 
UoOLR 


2001/09/22 19:10 


- 


0 


((service near20 levelSl) same filter$3) and tos 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:10 




261 


bandwidthSl and broker$3 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/22 19:10 
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- 


3 


((service near20 level$l) same filter$3) and (bandwidthSl and 
brokerS3) 


USPAT; 
EPO; 

DERWENT; 

T TSOPT? 
UoVyvlv 


2001/09/22 19:11 


- 


4909 


service near3 levelSl 


USPAT; 
EPO; 

DERWENT; 

i TSOPR 


2001/09/22 19:11 


- 


9939 


admission same control$4 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:12 


- 


19 


(service near3 level$l) same (admission same control$4) 


USPAT; 
EPO, 

DERWENT; 


2001/09/22 19:21 


- 


9448 


ingress and egress 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:21 


- 


3585 


bandwidth adj (allocat$4 or broker$5 or control$4 or request$3) 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:22 


- 


57 


(ingress and egress) and (bandwidth adj (allocat$4 or broker$5 or 
control$4 or request$3)) 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:22 


- 


13 


(service near3 levelSl) and ((ingress and egress) and (bandwidth adj 
(allocat$4 or broker$5 or control$4 or request$3))) 


USPAT; 
EPO; 

DERWENT; 

UoULK 


2001/09/22 19:26 


- 


168 


(admissionSl or access) adj profil$3 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:27 


- 


1190 


((709/226) or (709/225) or (709/229)).CCLS. 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:27 


- 


7 


((admissionSl or access) adj profil$3) and ((("709/226") or ("709/225") 
or ("709/229")).CCLS.) 


USPAT; 
EPO; 

DERWENT; 


2001/09/22 19:27 


- 


59 


policy adj serverSl 


USPAT; 
EPO; 

DERWENT; 

USULK 


2001/09/25 12:04 


- 


675 


713/15$.ccls. 


USPAT; 
EPO; 

DERWENT; 

UoULK 


2001/09/25 12:04 


- 


6 


(policy adj serverSl) and 713/15$.ccls. 


USPAT; 
EPO; 

DERWENT; 


2001/09/25 12:07 




1 


admissions 1 adj profile$l 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:29 
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- 


4276 


dynamic$5 near5 filter$3 


USPAT; 


2001/09/25 12:09 






EPO; 

DERWENT; 
USOLK 






2 


(dynamic$5 near5 filter$3) and (policy adj serverSl) 


IIODA T"- 

UorAl , 

EPO; 

DERWENT; 
USOCR 


2UUl/Uy/25 12.29 


- 


306 


filter$3 adj criteriaSl 


USPAT; 


2001/09/25 12:30 






EPO; 

DERWENT; 
USOCR 




- 


39 


admissionSl adj 10 profileSl 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:29 


- 


0 


(filter$3 adj criteriaSl) and (admissionSl adj 10 profileSl) 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:29 


- 


17 


(dynamic$5 near5 filter$3) and (filter$3 adj criteriaSl) 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:35 


- 


47 


ingress near4 profil$3 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:35 


- 


0 


(admissionSl adj 10 profileSl) and (ingress near4 profil$3) 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:35 


- 


0 


(ingress near4 profil$3) and 713/15$.ccls. 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:35 


- 


3 


(ingress near4 profil$3) and filter$3 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:38 


- 


102511 


remov$3 nearlO filter$l 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:40 


- 


84571 


remov$3 near5 filterSl 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:42 


- 


0 


(admissionSl adj 10 profileSl) and (remov$3 near5 filterSl) 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:42 


- 


2 


(policy adj serverSl) and (remov$3 near5 filterSl ) 


USPAT; 
EPO; 

DERWENT; 


2001/09/25 12:43 




4 


713/15$.ccls. and (removS3 near5 filterSl) 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/25 12:43 
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- 


867 


filter$3 nearS (delet$3 or expir$6) 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 10:48 


- 


8494 


713/$.ccls. 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 10:48 


- 


0 


(dynamically with (creat$3 or establish$3 or remov$3 or delet$3) with 
filter$l)and713/$.ccls. 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 10:48 


- 


20 


(filter$3 near5 (delet$3 or expir$6))and 713/$.ccls. 


USPAT; 
EPO; 

DERWENT; 

T ICHPD 


2001/09/26 12:24 


- 


89 


dynamically with (creat$3 or establish$3 or remov$3 or delet$3) with 
filterSl 


USPAT; 
EPO; 

DERWENT; 

TTQfVMJ 
UoULK 


2001/09/26 10:53 






dynamically near3 (creat$3 or establish$3 or remov$3 or delet$3) near3 
filters 1 


EPO; 

DERWENT; 

I TCHPD 
UoUL-K 


9flfil /ftO/Ofi 1 1 

1 1 M J 


- 


2 


("6148336").PN. 


USPAT; 


2001/09/26 11:45 






EPO; 

DERWENT; 

UoUL-K. 




- 


1 


(C'6148336").PN.) and (remov$3 or delet$3 or expir$7) 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 12:05 


- 


1 


((( M 6148336").PN.) and (remov$3 or delet$3 or expir$7)) and packetSl 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 12:06 


- 


1 


((C"6148336 n ).PN.) and (remov$3 or delet$3 or expir$7)) and 
(destinations 1 or sourceS 1 ) 


USPAT; 
EPO; 

DERWENT; 


2001/09/26 12:09 


- 


0 


(("6148336")-PN.) and (admission adj profileSl) 


USPAT; 
EPO; 

DERWENT; 
t tc nrD 


2001/09/26 12:10 




yj 


(("6148336").PN.) and (admission near4 profileSl) 


I TCP AT- 

UorAlj 

EPO; 

DERWENT; 






1 

1 


(("6148336").PN.) and polic$3 


T TCP A T- 








EPO; 

DERWENT; 




- 


1 


(("6148336").PN.) and (policy or policies) 


USPAT; 


2001/09/26 12:25 






EPO; 

DERWENT; 
USOCR 






26 


(("5554322") or ("5884033") or ("5953338") or ("5968176") or 
("6055571") or ("6130924") or ("6148336") or ("6167451") or 
("6167445") or ("6178505") or ("61991 13") or ("6256741") or 
("6262974") or ("6295527")).PN. 


USPAT; 
EPO; 

DERWENT; 
USOCR 


2001/09/29 18:39 
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3 


("5544322").PN. 


TTCPAT- 


zuui/uy/z? lo.jy 






brU, 










IJbKWblN 1 j 










UoUCK 






4260 


relational adj database 


I ICPAT- 


ZUUZ/IW/ 1 1 U.Uj 






brU, 










DbK WCJN 1 } 










T TO/^/^D 

UMJtK 






I 1 / /J 


/U //5.CCIS. 


T TOp AT- 


2002/04/1 1 1 3 05 








Lfv, 
























■ 


1757 


(relational adj database) and 707/5. eels. 


I ICPAT 


Trtfll/flA/l 1 1 1Pl£ 
ZUUZ/Un/ 1 1 1J.UO 




296 


((relational adj database) and 707/$.ccls.) and api 


T TCPAT 


ZUUi/U ± T/ 11 1 J .uo 




1778 


tngger$3 near5 futerSl 


T TCP AT 


ZUUZ/U^l/ 15 11 .zo 




i c 


(trigger*:) near.) nlterji j ana / ij/yccis. 


T TOD AT 


Xv/Wi/vlH/ loll 




1 


( 6178505 ).PN. 


T TCP AT 


onro /n/i/'>') fio-^o 
I\j\JAi\imi£ us.zv 




i 
I 


(( ol/isjU5 ).rlN.) ana expir* / 


TTCPAT 






1 (LI 
103 


tos same filter$3 


T Tcp AT 


ZUvZ/ 1 l/UO 1 J.4J 




6 


(tos same filter$3) same (type adj2 serviceSl) 


T TCPAT 


9009/1 1 /flfi 1 S-dS 
ZUUZ/11/UO IJ.U 




4611 


classify 8 same filter* 3 


T TCP AT 

UorAl 


ZUUz/ll/UO Ij.'fj 




5 


(classifSS same filter$3) same tos 


T TOT} A T 

UorAl 


inm/i 1 tc\(L i 
ZUUZ/ 1 1 /UO 1 _> .'lo 


- 


14 


(classif$8 same filter$3) and tos 


T TOD A T 

UorAl 


zUUZ/1 1/Uo l->.4o 




jj. 


packet adj classifierS 1 


T TO PAT- 

u or a i , 


90f)?/l 1/14 1fif)*i 






CD/"V 

brU, 










L)bK WbJN 1 , 










T FO C\f D 

UoUUK 






ZD 


(packet adj classifierS 1 ) and filterS3 


T to pAT- 
u or a i , 


9009/1 1/14 Ifi O'S 








brU; 










IJbK WbJN 1 , 










T TO r^f^T} 






Zl 


(packet adj classifierS 1 ) and (qos or tos) 


T Top AT- 


9009/1 1/14 160^ 








LIV, 










piTTD \trc\TT- 










t tc nro 








((packet adj classifierS 1 ) and filter$3) and ((packet adj classifierS 1) and 


T TCPAT- 
UorAl, 


ZUUZMl/lt 10.lt 






(qos or tos)) 


br \J, 










UtKWrJN 1 , 










T TOP^D 






4 


( 5636371 | 5729685 | 5802286 | 5826U14 ).rJN. 


T TOD AT 

UorAl 


iUUZ/1 1/11 10. 1 J 




OS 


witting, inv. 


TTCPAT- 

UorAl , 


TflfC7/l 1/1/1 1 A- 1 4 
ZUUZMl/l 4 ! lO.l'l 








CDA- 

brU, 










TXC DAI rCXTT- 

UbKWbJN 1 , 










T TO/^/^D 

UoOUK 






Z 


... 
witting, in v. and filter$3 


T TOPAT- 
UorA 1 , 


9009/1 1 /14 1 S 
ZUUZ/ll/lt IO.Ij 








brU, 










r\tr d \i rtrxrr. 
JJbKWbJN 1 , 










T TO/^r'D 






i 
1 


witting, inv. and packets 1 


T TOD AT- 

UorAl, 


info /i i /i /i 1^-1^ 
ZUUZ/1 1/11 10. ID 








brU, 










r\rr D \\ rcxrT. 

UbKwbN 1 ; 










USOCR 






253 


barzilai 


T TOT) A T, 

UorAl; 


2U0Z/1 1/lt 10. ID 








brU; 










UbKWbN 1 ; 
















17 


barzilai.inv. 


USPAT; 


2002/11/14 16:16 








EPO; 










DERWENT; 










USOCR 
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- 


77 


barzilai and packets 1 


USPAT; 


2002/11/14 16:16 






EPO; 

DERWENT; 
USOCR 




- 


9 


(barzilai and packetSl ) and classify 


USPAT; 
EPO; 

DERWENT; 

t to 

USOCR 


2002/11/14 16:18 




16 


"5040176" 


T TC O A T. 

USrAl, 
EPO; 

DERWENT; 

T TO f\f^Ti 

USOCR 


l\)\W\ 1/ 14 lo.lo 




2 


5040176.pn. 


T ICDAT' 


zuuz/i 1/ 14 lo.zu 






EPO; 

DERWENT; 
USOCR 






5 


tsipora and barzilai. in v. 


ITODAT- 


L\)\)ll 1 1/14 lo.ZU 






EPO; 

DERWENT; 

T TO /""N/Tn 

USOCR 






0 


(tsipora and barzilai. inv.) and filter$3 


T TCT> A T. 
USPA1 , 


^rirto /1 1 /1 a i£.ii 
200271 1/14 10.21 






EPO; 

DERWENT; 

T TO /~\/ F ~"\ n 

USOCR 






0 


(tsipora and barzilai. in v.) and qos 


TTODAT- 

USrAl, 


1 Aftl f\ 1 /I A 1 £-1 1 

20U2/1 1/14 10.21 






EPO; 

DERWENT; 

t to rv/rn 

USOCR 




- 


1 


(tsipora and barzilai. inv.) and classification 


USPAT; 


2002/11/14 16:24 






EPO; 

DERWENT; 

T TO /^\/TTl 

USOCR 






13 


wittig and hartmut 


T TOT! A T, 

USPAT; 
EPO; 

DERWENT; 
USOCR 


2002/1 1/14 lo.iy 




3 


(("6084879") or ("6335935") or ("6157955")).PN. 


USPAT 


2002/ll/H I6:3l 




522 


packet adj classn$8 


T TO T» A T. 

USPAT; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


^\r\r\-y /A A fjf\ 11,11 

2003/04/30 l l:l2 




287 


(nic or (network adj (interface or adapter))) near5 filterS3 


T TO Ti A T'. 

USPAT; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
EBM_TDB 


2003/04/30 11:13 




60477 


370/$.ccls. 


T to n A t. 

USPAT; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBMTDB 


^fiA'l ff\A t*5f\ 1 1 .AH 

2003/04/30 11:09 




74 


370/$.ccls. and ((nic or (network adj (interface or adapter))) near5 
filter33) 


T TO n A r V 

USPAT; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


^/Vf\^ li\A f*> f\ 1 1 .1 A 

2003/04/30 11:10 




o 
5 


(370/$,ccls. and ((nic or (network adj (interface or adapter))) nearS 
filter$3)) and classif$8 


T TCP AT- 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM TDB 


Tftni/fidrtn 1 i-in 

ZUUj/U4/jLF 11.1U 



Search History 4/30/03 12:49:59 PM Page 6 
C:\APPS\EASTWorkspaces\09222340.current. wsp 





13 


(packet adj classing) and ((nic or (network adj (interlace or adapter))) 
near5 filter$3) 


f TOT"} A T. 

USrAl; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
D3MTDB 


IrtfiK/l/IMn 11,1(1 

2003/04/30 11:1U 




1303 


(mc or (network adj (interface or adapter or controller))) same iilter$3 


T TODA X- 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


inrt'j ic\a iit\ 11-11 
2003/04/30 1 1.13 




1511 


(frame or packet or cell) adj classiijs 


TTCDAT. 

USrAl, 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


^(\f\Hf\A lift i i.n 
zU(J3/(J4/3U 1 1 . 1 J 




311 


(nic or (network adj 2 (interface or adapter))) near 5 filter$3 


T TOD A T. 

USrAl; 
US-PGPUB; 
EPO; JPO; 
DERWENT; 
BM_TDB 


"> r\r\i if\ a ii f\ ii.li 
2UU3/U4/3U 11.13 




1 AC(. 

14oo 


(nic or (network adj 2 (interface or adapter or controller))) same ftlter$3 


ITCDAT- 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


inni t(\A Jin 1 1 - I a 
2UU3/U4/3U 1 1.14 




15 


((nic or (network adj 2 (interface or adapter))) near5 filter$3) and 
((frame or packet or cell) adj classify 8) 


T TOT) A T. 

USrAl; 
US-PGPUB; 

rnA, Tt)A. 

ErU; JrO; 
DERWENT; 
IBM TDB 


2u03/U4/3u 11.16 


- 


7 


("5774660" | "5918021" | "6151297" | "6160544" | "6243360" | 
"6253334"| "63 14525").PN. 


USPAT 


2003/04/30 11:15 




4 


(( 5//4oo0 J 5yiSU21 | o 15129/ | oIoUj44 [ 6243360 j 
"6253334" | M 6314525 M ).PN.) and filter$3 


TTCDAT. 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM_TDB 


^ftftl l(\A lift 1 I.IO 

2003/04/30 11.18 






((nic or (network adj 2 (interface or adapter or controller))) same 
filterS 3) and ((frame or packet or cell) adj classify 8) 


T TCP AT- 
UorA 1 , 

US-PGPUB; 
EPO; JPO; 
DERWENT; 
IBM TDB 


onni/fiji/in ^'^)•A'X 
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[57] 



ABSTRACT 



A computer network having multiple, dissimilar network 
devices includes a system for implementing high-level, 
network policies. The high-level policies, which are gener- 
ally device -independent, are translated by one or more 
policy servers into a set of rules that can be put into effect 
by specific network devices. Preferably, a network admin- 
istrator selects an overall traffic template for a given domain 
and may assign various applications and/or users to the 
corresponding traffic types of the template. Location- 
specific policies may also be established by the network 
administrator. The policy server translates the high-level 
policies inherent in the selected traffic template and location- 
specific policies into a set of rules, which may include one 
or more access control lists, and may combine several 
related rules into a single transaction. Intermediate network 
devices, which may have one or more roles assigned to their 
interfaces, are configured to request traffic management 
information from the policy server which replies with a 
particular set of transactions and rules. The rules, which may 
correspond to the particular roles assigned to the interfaces, 
are then utilized by the intermediate devices to configure 
their particular services and traffic management mecha- 
nisms. Other rules are utilized by the intermediate devices to 
classify packets with a particular priority and/or service 
value and to treat classified packets in a particular manner so 
as to realize the selected high-level policies within the 
domain. 

18 Claims, 9 Drawing Sheets 
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METHOD AND APPARATUS FOR DEFINING 
AND IMPLEMENTING HIGH-LEVEL 
QUALITY OF SERVICE POLICIES IN 
COMPUTER NETWORKS 

FIELD OF THE INVENTION 

The present invention relates generally to computer 
networks, and more specifically, to a method and apparatus 
for applying high-level, quality of service policies at dis- 
similar computer network devices. 

BACKGROUND OF THE INVENTION 

A computer network typically comprises a plurality of 
interconnected entities thai transmit (i.e., "source") or 
receive (i.e., "sink") data frames. A common type of com- 
puter network is a local area network ("LAN") which 
typically refers to a privately owned network within a single 
building or campus. LANs employ a data communication 
protocol (LAN standard), such as Ethernet, FDDI or token 
ring, that defines the functions performed by the data link 
and physical layers of a communications architecture (i.e., a 
protocol stack), such as the Open Systems Interconnection 
(OSI) Reference Model. In many instances, multiple LANs 
may be interconnected by point-to-point links, microwave 
transceivers, satellite hook-ups, etc. to form a wide area 
network ("WAN"), metropolitan area network ("MAN") or 
intranet. These LANs and/or WANs, moreover, may be 
coupled through one or more gateways to the Internet. 

One or more intermediate devices are often used to couple 
LANs together and allow the corresponding entities to 
exchange information. For example, a bridge may be used lo 
provide a "bridging" function between two or more LANs. 
Alternatively, a switch may be utilized to provide a "switch- 
ing" function for transferring information, such as data 
frames, among entities of a computer network. Typically, the 
switch is a computer having a plurality of ports that couple 
the switch to several LANs and to other switches. The 
switching function includes receiving data frames at a 
source port and transferring them to at least one destination 
port for receipt by another entity. 

Switches may operate at various levels of the communi- 
cation protocol stack. For example, a switch may operate at 
layer 2 which, in the OSI Reference Model, is called the data 
link layer and includes the Logical Link Control (LLC) and 
Media Access Control (MAC) sub-layers. Data frames at the 
data link layer typically include a header containing the 
MAC address of the entity sourcing the message, referred to 
as the source address, and the MAC address of the entity to 
whom the message is being sent, referred to as the destina- 
tion address. To perform the switching function, layer 2 
switches examine the MAC destination address of each data 
frame received on a source port. The frame is then switched 
onto the destination port(s) associated with that MAC des- 
tination address. 

Other devices, commonly referred to as routers, may 
operate at higher communication layers, such as layer 3 of 
the OSI Reference Model, which in TCP/IP networks cor- 
responds to the Internet Protocol (IP) layer. Data frames at 
the IP layer also include a header which contains an IP 
source address and an IP destination address. Routers or 
layer 3 switches may re-assemble or convert received data 
frames from one LAN standard (e.g., Ethernet) to another 
(e.g. token ring). Thus, layer 3 devices are often used to 
interconnect dissimilar subnetworks. 

User Priority 

FIG. 1 is a block diagram of a data link (e.g., Ethernet) 
frame 100 which includes a MAC header 102 and a data 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



field 104. MAC header 102 includes a MAC destination 
address (MAC DA) field 106 and a MAC source address 
(MAC SA) field 108. Recently, a proposal was made to 
insert a new field after the MAC SA field 108. More 
specifically, the Institute of Electrical and Electronics Engi- 
neers (IEEE) is working on a standard, the IEEE 802.1 Q 
draft standard, for adding information to MAC headers. In 
particular, the 802.1Q standard defines a tag header 110 
which is inserted immediately following the MAC DA and 
MAC SA fields 106, 108. 

The tag header 110 comprises a plurality of sub-fields, 
including a Tag Protocol Identifier (TPID) field 112, a 
user_priority field 114, a Canonical Format Indicator (CFI) 
field 116 and a Virtual Local Area Network Identifier 
(VLAN ID) field 120. The user_priority field 114 permits 
network devices to select a desired priority of data link 
frames. In particular, in an IEEE appendix, referred to as the 
802. lp standard, the IEEE has defined eight possible values 
of user priority (0-7), each of which is associated with a 
specific traffic type. The proposed user priority values and 
corresponding traffic types specified in the 802. lp standard 
are as follows. 



User Priority 






Value 


Traffic Type 


Description 


1 


Background 


bulk transfers 


2 


Spare/Reserved 


ry'a 


0 


Best Effort 


current LAN traffic 


3 


Excellent Effort 


best effort type of services 






(e.g., for an organization's 






most important customers) 


4 


Controlled Load 


important business 






applications 


5 


Video (<100 milliseconds 


minimum jitter 




latency and jitter) 




6 


Voice (<10 milliseconds 


one-way transmission through 




latency and jitter) 


the LAN 


7 


Network Control 


characterized by a "must gel 






there" requirement to maintain 






and support the network 






infrastructure 



An intermediate device may provide a plurality of trans- 
mission priority queues per port and, pursuant to the 802. lp 
standard, may assign frames to different queues of a desti- 
nation port on the basis of the frame's user priority value. 
For example, frames with a user priority of "0" are placed 
in the "0" level priority queue (e.g., non-expedited traffic), 
whereas frames with a user priority of "3" are placed in the 
level "3" priority queue. Furthermore, frames stored in a 
higher level queue (e.g., level 3/excellent effort) are prefer- 
ably forwarded before frames stored in a lower level queue 
(e.g., level 1/background). This is commonly referred to as 
Priority Queuing. Thus, by setting the contents of the 
user_priority field 114 to a particular value, a device may 
affect the speed with which the corresponding frames 
traverse the network. 

If a particular intermediate device has less than eight 
priority queues per port, several of the IEEE traffic types 
may be combined. For example, if only three queues are 
present, then queue 1 may accommodate best effort, excel- 
lent effort and background traffic types, queue 2 may accom- 
modate controlled load and video traffic types and queue 3 
may accommodate voice and network control traffic types. 
The IEEE 802. lp standard also recognizes that intermediate 
devices may regenerate the user priority value of a received 
frame. That is, an intermediate device may forward the 
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frame with a different user priority value (still within the predefined criteria. When a packet is received by such a 

range of 0-7) than the one it had when the frame was device, it is tested against each of the criteria statements of 

received. Nevertheless, the standard recommends leaving the corresponding list. If a match is found, the packet is 

the user priority value un-changed. either forwarded or dropped as provided by the List. The 

Type of Service 5 cr i tcf i a mav De source address, destination address, or 

FTG. 2 is a block diagram of a portion of an Internet «PP«-laycr application based on their TCP/UDP port nuu> 

Protocol Version 4 (IPv4) compliant IP header 200. The IP ^ t ^ ™ y ^ c *fJ 0 bC 

header 200 is also made up of a plurality of fields, including f°™*ded but cause all Telnet traffic to be dropped. Access 

atype of_service (ToS) field 202, a time to live (TTL) field ^ may be established for both inbound and outbound 

204, m IP source address (IP SA) field 206 and an IP 10 traffic and are most commonly configured at layer 3 deuces 

destination address (IP DA) field 208. The ToS field 202 is ^ ocate f 1 at thc b ° rdcr of a nci ™ tk ( l \> S atcwa y s or 

intended to allow an entity to specify the particular service firewalk ) t0 P rovide sccunt y to «** network - 

it wants, such as high reliability, fast delivery, accurate Congestion Control 

delivery, etc., and comprises a number of sub-fields. The Congestion typically refers to the presence of too many 

sub-fields include a three bit IP precedence (IPP) field 210, 15 packets in a subnet or a portion of a network, thereby 

three one bit flags (D, T and R) 212, 214 and 216 and two degrading the network's performance. Congestion occurs 

unused bits 218. By setting the various flags, a host may when the network devices are unable to keep up with an 

indicate which overall service it cares most about (i.e., increase in traffic. As described above, a layer 3 device 

Delay, Throughput and Reh ability). Although the ToS field typically has one or more priority queues associated with 

202 was intended to allow layer 3 devices to choose between 20 each interface. As packets are received, they arc added to the 

different links (e.g., a satellite link with high throughput or appropriate priority queue for forwarding. Nevertheless, if 

a leased line with low delay) depending on the service being packets are added to the queue faster than they can be 

requested, in practice, most layer 3 devices ignore the forwarded, the queue will eventually be filled forcing the 

contents of the ToS field 202 altogether. Instead, protocols at device to drop any additional packets for that queue. The 

the transport layer (layer 4) and higher typically negotiate 25 dropping of packets when a queue is full is referred to as tail 

and implement an acceptable level of service. Version 6 of drop. The point at which tail drop occurs, moreover, may be 

the Internet Protocol (IPv6) similarly defines a traffic class configured to something less than the capacity of the queue, 

field, which is also intended to be used for defining the type Since tail dropping discards every packet over the queue 

of service to be applied to the corresponding packet. limit, it often affects multiple upper layer applications simul- 

Recently, a working group of the Internet Engineering taneously. Furthermore, many upper layer applications, such 

Task Force (IETF), which is an independent standards as TCP, re-send messages if no acknowledgments are 

organization, has proposed replacing the ToS field 202 with received. Thus, the presence of tail dropping can cause 

a one octet differentiated services (DS) field 220. The first global synchronization among upper layer applications, sig- 

six bits of the DS field specify a differentiated services 35 nificantly exacerbating the congestion problem. To avoid 

codepoint while the last two bits are unused. Layer 3 devices global synchronization, some layer 3 devices use Random 

that are DS compliant apply a particular per-hop forwarding Early Detection (RED), which selectively drops packets 

behavior to packets based on the contents of their DS fields when congestion first begins to appear. By dropping some 

220. Examples of per-hop forwarding behaviors include packets early before the priority queue is full, RED avoids 

expedited forwarding and assured forwarding. The DS field ^ dropping large numbers of packets all at once. In particular, 

220 is typically loaded by DS compliant intermediate when a calculated average queue depth exceeds a minimum 

devices located at the border of a DS domain, which is a set threshold, the device begins dropping packets. The rate at 

of DS compliant intermediate devices under common net- which packets are dropped increases linearly as a function of 

work administration. Thereafter, interior DS compliant a probability constant. When a maximum threshold is 

devices along the path simply apply the assigned forwarding 4S reached, all additional packets are dropped. An extension to 

behavior to the packet. RED is Weighted Random Early Detection (WRED), which 

Although layer 3 devices, like their layer 2 counterparts, applies different thresholds and probability constants to 

typically have multiple priority queues per port or interface, packets associated with different traffic flows. Thus, WRED 

layer 3 devices often apply scheduling patterns that are more al l° ws standard traffic to be dropped more frequently than 

sophisticated than simple Priority Queuing. For example, 50 premium traffic during periods of congestion, 

some layer 3 devices forward one packet from each queue in Service Level Agreements 

a round robin fashion. Another approach, referred to as fair To interconnect dispersed computer networks, many orga- 

queuing, simulates a byte-by-byte round robin to avoid nizations rely on the infrastructure and facilities of service 

allocating more bandwidth to sources who transmit large providers. For example, an organization may lease a number 

packets than to those who only send small packets. Another 55 0 f Tl lines to interconnect various LANs. These organiza- 

approach, called Weighted Fair Queuing (WFQ), allocates uons typically enter into service level agreements with the 

more bandwidth to specific traffic flows or sources, such as service providers, which include one or more traffic speci- 

file servers, based on source IP address, Transmission Con- fi ers . These traffic specifiers may place limits on the amount 

trol Protocol (TCP) or User Datagram Protocol (UDP) of resources that the subscribing organization will consume 

source port, etc. 60 f or a given charge. For example, a user may agree not to 

Some networking software, including the Internetwork send traffic that exceeds a certain bandwidth (e.g., 1 Mb/s). 

Operating System (IOS) from Cisco Systems, Inc., support Traffic entering the service provider's network is monitored 

the creation access control lists or filters, which are typically (i.e., "policed") to ensure thai it complies with the relevant 

used to prevent certain traffic from entering or exiting a traffic specifiers and is thus "in-profile". Traffic that exceeds 

network. In particular, certain layer 3 devices utilize access 65 a traffic specifier (i.e., traffic that is "out-of-profile") may be 

lists to control whether routed packets should be forwarded dealt with in a number of ways. For example, the exceeding 

or filtered (i.e., dropped) by the device based on certain traffic may be dropped or shaped. With shaping, the out-of- 
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profile traffic is temporarily stored until the demand drops 
below the threshold. Another option is to mark the traffic as 
exceeding the traffic specifier, but nonetheless allow it to 
proceed through the network. If there is congestion, an 
intermediate device may drop this "marked" or down graded 
traffic first in an effort to relieve the congestion. Another 
option is to change the accounting actions for this out-of- 
profile traffic (i.e., charge the user a higher rate). 

Allocation of Network Resources 

As shown, computer networks include numerous services 
and resources for use in moving traffic around the network. 
For example, different network links, such as Fast Ethernet, 
Asynchronous Transfer Mode (ATM) channels, network 
tunnels, satellite links, etc., offer unique speed and band- 
width capabilities. Particular intermediate devices also 
include specific resources or services, such as number of 
priority queues, filter settings, availability of different queue 
selection strategies, congestion control algorithms, etc. 
Nonetheless, these types of resources or services are highly 
device-specific. That is, most computer networks include 20 
intermediate devices manufactured by many different 
vendors, employing different hardware platforms and soft- 
ware solutions. Even intermediate devices from the same 
vendor may be running different software versions and thus 
provide different functionality. Thus, there is no consistency 25 
of resources at each of the intermediate devices and, 
therefore, it is generally not possible to simply select a single 
set of parameters for use in configuring all of them. 

In addition, the allocation of network resources and 
services is becoming an important issue to network admin- 
istrators and service providers as greater demands are being 
placed on their networks. Nonetheless, at the present time, 
there are few if any techniques available for applying traffic 
management policies across a network. Instead, the alloca- 
tion of network resources and services is typically achieved 
by manually configuring the interfaces of each intermediate 
device. For example, to the extent there are parameters 
associated with a particular queuing strategy available at a 
given intermediate device (e.g., queue length for tail drop 
and minimum, maximum and mark probability for RED), 
these parameters must be set de vice-by -device by the net- 
work administrator. This is a time consuming and error 
prone solution. In addition, there are few if any tools 
currently available to network administrators suggesting 
how various network resources and services might be coher- 
ently allocated in order lo implement any general policies. 
Accordingly, the ability to allocate network services and 
resources to implement network-wide quality of service 
policies is difficult and time-consuming. 
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SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a method 
and apparatus for applying high-level quality of service 
policies. 

It is a further object of the present invention to provide a 
method and apparatus for translating high-level policies into 
a form that may be understood and applied by numerous 
dissimilar network devices. 



one or more policy servers into a set of rules that can be 
applied by specific network devices. In particular, a network 
administrator first selects an overall traffic template for a 
given network domain and may assign various applications 
and/or users lo the corresponding traffic types of the tem- 
plate. The network administrator may also select or define 
one or more location-specific policies. As information is 
added to the template and the location-specific policies are 
defined, one or more corresponding data structures may be 
up-dated. The selected traffic template, location-specific 
policies and data structures are received at one or more 
policy servers within the network domain. Each policy 
server translates the high-level policies inherent in the 
selected traffic template, location-specific policies and data 
structures into a set of rules and may combine several related 
rules into a single transaction. Upon initialization, interme- 
diate devices request traffic management information from 
the one or more policy servers. The policy server replies 
with a particular set of transactions and rules that are utilized 
by the intermediate devices for traffic management deci- 
sions. By propagating these rules across the network 
domain, each of the dissimilar intermediate devices can 
configure its corresponding traffic management components 
and mechanisms to operate in such a manner as to imple- 
ment the high-level policies selected by the network admin- 
istrator. 

More specifically, a particular differentiated service (DS) 
codepoint is preferably assigned to each traffic type of the 
selected traffic template, based on the overall priority estab- 
lished by the network administrator. The DS codepoint 
essentially sets the overall treatment of the corresponding 
traffic type within the network domain. Aset of classification 
rules are then generated by the policy server instructing 
intermediate devices to associate particular traffic types with 
their corresponding DS codepoints. For example, the clas- 
sification rules may direct intermediate devices to load a 
particular DS codepoint within the DS field of received 
Internet Protocol (IP) messages, depending on the type of IP 
message (e.g., all traffic associated with a stock exchange 
application). Devices that are not DS-compliant may receive 
classification rules instructing them to load a given value 
within type__of_service or user_priority fields of received 
packets or frames. The classification rules, which may 
include one or more access control lists, are preferably 
provided to all intermediate devices located at the boundary 
of the network domain so that traffic can be associated with 
its corresponding DS codepoint as soon as it enters the 
domain. Classification rules may also be used lo associate 
Quality of Service (QoS) labels to specific traffic types. QoS 
labels are also used by intermediate devices in making traffic 
management decisions, although, unlike the DS codepoints 
which are generally present in messages traveling the 
network, QoS labels are only associated with messages 
while they remain within the intermediate device. Classifi- 
cation rules may also be used to assign DS codepoints and/or 
QoS labels to data traffic generated within the network 
domain from un- trusted sources. 

To implement specific traffic management policies or 
treatments, the policy server also defines a plurality of 



It is a further object of the present invention to classify 60 behavioral rules that basically instruct the intermediate 



data traffic upon its entering a given network domain and to 
manage that traffic based on its classification. 

Briefly, the invention relates to a method and apparatus 
for implementing high-level policies within a computer 
network having multiple, dissimilar network devices. The 
high-level policies, which are generally device-independent, 
are selected by a network administrator and translated by 



devices how to manage data traffic that has been associated 
with a particular DS codepoint, QoS label, type of service 
and/or user priority value. For example, a behavioral rule 
may instruct the intermediate devices to place all messages 
associated with a particular DS codepoint (e.g., data frames 
from a stock exchange application or from a corporate 
executive) in a high priority queue. To implement traffic 
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management policies that are independent of DS codepoints switch 308 and routers 316-318, by links 324a-324c, The 

and/or QoS labels, the policy servers preferably generate one network 300 also includes one or more repositories, such as 

or more configuration rules. Configuration rules generally repository 326, that is preferably connected to each policy 

instruct intermediate devices how to set-up their various server 322 by a link 328. The repository 326 may be an 

traffic management components or mechanisms. For 5 organization-based directory server, 

example, a configuration rule may contain a list of conges- The network 300 may further include one or more 

tion algorithms in descending order of preference. Upon Dynamic Host Configuration Protocol (DHCP) servers, sucb 

receipt of the configuration rule, an intermediate device 35 server 329 > is also coupled to the policy server 322 

examines the list and preferably adopts the first congestion * lther ^ ect ^ Dr ^fj^ ^' ^u * r f 

algorithm that it supports lu Rc ^ csi for Comments (RFC) 2131, is built upon a chent- 

* ' server model, where DHCP servers allocate IP addresses and 

In the preferred embodiment, the policy servers and deliver nelwork configuration parameters to DHCP clients 

intermediate devices utilize an extension to the Common ^.g., hosts or end stations). Because IP addresses can be a 

Open Policy Service (COPS) protocol to exchange mes- scarce resource in some computer networks, DHCP servers 

sages. More specifically, an intermediate device sends a assign them only for limited periods of time (referred to as 

Query Configuration message to the policy server that 1 5 a lease). Once a lease has expired, the corresponding IP 

contains specific information about itself, such as the mim- address may be re-assigned to another host, 

ber and type of interfaces, whether the device is at a Attached to the switches 306-314 and routers 316-318 

boundary of the intermediate domain and/or whether its are a plurality of end stations 330-346 and servers 348-352, 

interfaces are coupled to trusted or un-trusted devices. This which may be file servers, print servers, etc. In particular, 

device-specific information may be loaded in the query 20 four end stations 330-336 are connected to switch 306, one 

message as COPS objects. In response, the policy server end station 338 and one server 348 are connected to switch 

selects a particular set of transactions or rules responsive to 308, two end stations 340 and 342 are connected to switch 

the device-specific information and provides them to the 310, one server 350 is connected to router 318, two end 

intermediate device. Preferably, the transactions and rules stations 344 and 346 are connected to switch 312, and one 

are similarly embedded as COPS objects in response mes- 25 server 352 is connected to switch 314. 

sages. As described above, the intermediate device reviews Software entities (not shown) executing on the various 

these transactions and rules and implements those rules end stations 330-346 and servers 348-352 typically com- 

which are compatible with its particular traffic management municate with each other by exchanging discrete packets or 

components and mechanisms. * ames ? f data * - predefined protocols such^s the 

v 30 Transmission Control Protocol/Internet Protocol (TCP/IP), 

BRIEF DESCRIPTION OF THE DRAWINGS the Internet Packet Exchange (IPX) protocol, the AppleTalk 

protocol, the DECNet protocol or NetBIOS Extended User 

The above and further advantages of the invention may be Interface (NetBEUI). In this context, a protocol consists of 

better understood by referring to the following description in a xt 0 f m i cs defining how the entities interact with each 

conjunction with the accompanying drawings, in which: 35 other Data transmission over the network 300 consists of 

FIG. 1, previously discussed, is a block diagram of a prior generating data in a sending process executing on a first end 

art frame; station, passing that data down through the layers of a 

FIG. 2, previously discussed, is a block diagram of a protocol stack where the data are sequentially formatted for 

portion of a prior art Internet Protocol (IP) header; delivery over the links as bits. Those frame bits are then 

FIG. 3 is a highly schematic, partial diagram of a com- 40 received at the destination station where they are 

puter network- re-assembled and passed up the protocol stack to a receiving 

__ . . ' . . , . . . 1 j* , process. Each layer of the protocol stack typically adds 

FIG. 4 is a highly schematic partial block diagram of a information (in lhc form of a headcr) to mc data tcd 

policy server in accordance with the present invention; by ^ uppcr kycf as ^ dala dcsccnds ^ &tack M ^ 

FIG. 5 is a highly schematic, partial block diagram of an 45 destination station, these headers are stripped off onc-by-one 

intermediate device in accordance with the present inven- ^ tne f rame pr0 p ag ates up the layers of the stack until it 

ti° n I arrives at the receiving process. 

FIG. 6 is a preferred traffic template that may be selected Preferably, routers 316-318 are layer 3 intermediate 

by a network administrator; and devices and thus operate at the internetwork layer of the 

FIGS. 7A-7F are block diagrams of data structures asso- 50 communication protocol stack implemented within the net- 

ciated with the template of FIG. 6. work 300. For example, routers 316-318 preferably include 

an Internet Protocol (IP) software layer, as defined by the 

DETAILED DESCRIPTION OF THE well-known TCP/IP Reference Model. Routers 316-318 

PREFERRED EMBODIMENT implement network services such as route processing, path 

FIG. 3 is a highly schematic block diagram of a computer 55 determination and path switching functions. Switches 

network 300. The network 300 may be segregated into one 306-314 may be layer 2 intermediate devices and thus 

or more network domains by a network administrator, such operate at the data link layer of the corresponding commu- 

as network domains 302 and 304, as described below. The nication protocol stack. Switches 306-314 provide basic 

network 300 includes a plurality of entities, such as end bridging functions including filtering of data traffic by 

stations and servers, interconnected by a plurality of inter- so medium access control (MAC) address, "learning" of a 

mediate devices, such as bridges, switches and routers. In MAC address based upon a source MAC address of a frame 

particular, network 300 includes a plurality of switches and forwarding of the frame based upon a destination MAC 

306-314 and routers 316-318 interconnected by a number address or route information field (RIF). Switches 306-314 

of links 320a to 320/ which may be high-speed point-to- may further provide certain path switching and forwarding 

point or shared links. Each domain 302 and 304, moreover, 65 decision capabilities normally only associated with routers, 

includes at least one policy server 322 that is preferably In the illustrated embodiment, the switches 306—314 and 

connected to one or more intermediate devices, such as routers 316-318 are computers having transmitting and 
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receiving circuitry and components, including network 
interface cards (NICs) establishing physical ports, for 
exchanging data frames. The switches 306-314 and routers 
316-318 further comprise programmable processing 
elements, which may contain software programs pertaining 
to the methods described herein. Other computer readable 
media may also be used to store the program instructions. In 
addition, associated with each port or physical network 
connection is one or more logical connections or interfaces 
defined by the IP software layer. 

The terms router or layer 3 intermediate device as used 
herein are intended broadly to cover any intermediate device 
operating primarily at the internetwork layer, including, 
without limitation, routers as defined by Request for Com- 
ments (RFC) 1812 from the Internet Engineering Task Force 
(IETF), intermediate devices that are only partially compli- 
ant with RFC 1812, intermediate devices thai provide addi- 
tional functionality, such as Virtual Local Area Network 
(VLAN) support, IEEE 802. 1Q support and/or IEEE 802.1 D 
support, etc. The terms switch and layer 2 intermediate 
device are also intended to broadly cover any intermediate 
device operating primarily at the data link layer, including, 
without limitation, devices that arc fully or partially com- 
pliant with the IEEE 802.1D standard and intermediate 
devices that provide additional functionality, such as Virtual 
Local Area Network (VLAN) support, IEEE 802.1 Q support 
and/or IEEE 802.1p support, Asynchronous Transfer Mode 
(ATM) switches, Frame Relay switches, etc. 

It should be understood that the network configuration 
300 of FIG. 3 is for illustrative purposes only and that the 
present invention will operate with other, possibly far more 
complex, network topologies. It should be further under- 
stood that the repository may be indirecdy connected to the 
policy servers (e.g., through one or more intermediate 
devices). 

As described above, computer networks often include 
intermediate devices from many different vendors or, even if 
from the same vendor, having different hardware architec- 
tures or executing different versions of software. 
Accordingly, these intermediate devices provide many dif- 
ferent features and options. For example, a first switch may 
provide only 2 priority queues per port, whereas a second 
switch may provide 8 priority queues per port. With regard 
to congestion algorithms and techniques, some intermediate 
devices may only support tail dropping, while others may be 
selectively configured to provide random early detection 
(RED). Thus, it is extremely difficult for a network admin- 
istrator to configure all of the intermediate devices in 
accordance with a single, uniform traffic management plan. 
As result, network-wide quality of service is generally not 
available. As described herein, the present invention pro- 
vides a method and apparatus for allowing network admin- 
istrators to apply high-level traffic management policies that 
attempt to impose such a uniform plan, despite the presence 
of dissimilar intermediate devices in their networks. The 
traffic management policies, moreover, may be automati- 
cally propagated to and implemented by the various inter- 
mediate devices. 

FIG. 4 is a highly schematic, partial block diagram of 
policy server 322 in accordance with the preferred embodi- 
ment of the present invention. The policy server 322 is 
comprised of several components, including a policy trans- 
lator 410 having one or more storage devices 412a-412c. 
Policy server 322 also includes a policy validation tool 
(PVT) 413 and a policy rule generating engine 414 that are 
each in communication with the policy translator 410, a 
device-specific filter entity 416 and a communication engine 
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418. As shown, the device-specific filter entity 416 commu- 
nicates with both the policy rule generating engine 414 and 
the communication engine 418. The communication engine 
418, moreover, is preferably configured to exchange mes- 

5 sages with the intermediate devices (e.g., switches 306-314 
and routers 316-318) of network 300. That is, communica- 
tion engine 418 is connected to or includes conventional 
circuitry for transmitting and receiving messages across 
network links, such as links 324a-324c. 

1° A server suitable for use as policy server 322 is any 
Intel/Windows NT® or Unix-based platform. 

FIG. 5 is a partial block diagram of an intermediate 
device, such as router 318, in accordance with the preferred 
embodiment of the present invention. Router 318 preferably 

15 includes a communication engine 510 that is coupled to a 
traffic management controller 512. The communication 
engine 510 is configured to exchange messages with the 
policy server 322. That is, communication engine 510, like 
the communication engine 418 at policy server 322, is 

20 similarly connected to or includes conventional circuitry for 
transmitting and receiving messages across the network 300. 
The traffic management controller 512, which includes a 
policy rule decoder 514, is coupled to several components 
and mechanisms. In particular, traffic management control- 

25 ler 512 is coupled to a packet/frame classifier 516, a traffic 
conditioner entity 518, a queue selector/mapping entity 520 
and a scheduler 522. The traffic conditioner 518 also 
includes several sub -components, including one or more 
metering entities 524, one or more marker entities 526 and 

30 one or more shaper/dropper entities 528. The queue selector/ 
mapping entity 520 and scheduler 518 operate on the various 
queues established by router 318 for its ports and/or 
interfaces, such as queues 530a-530e corresponding to an 
interface 532. 

Creation of QoS Domains and Selection of High-Level 
Policies 

First, the network administrator preferably identifies vari- 
ous regions of his or her computer network 300 to which he 
or she wishes to have different, high-level traffic manage- 
ment polices applied. The identification of such regions may 
depend on any number of factors, such as geographic 
location, business unit (e.g., engineering, marketing or 
administrative), anticipated network demands, etc. The net- 

45 work administrator preferably defines a separate Quality of 
Service (QoS) or network domain for each region and 
assigns a primary policy server (e.g., policy server 322) to 
each QoS domain (e.g., domain 302). Thus, a QoS domain 
is basically a logical set of entities and intermediate devices 

50 defined by the network administrator. As described below, 
the primary policy server is responsible for propagating the 
high-level traffic management polices to the intermediate 
devices within its QoS domain. 

It should be understood that the policy server 322 may, 

55 but need not, be physically located within its QoS domain. 
It should be further understood that back-up or standby 
policy servers may also be assigned to the QoS domaios 
should any primary policy server fail. 

In addition, the boundaries of the network domains 302, 

60 304 may be established so as to only include trusted devices. 
A "trusted device" is an entity (e.g., an end station or server) 
which is considered to correctly classify the packets that it 
sources and to keep its transmission of packets in-profile 
(i.e., within the bounds of the traffic specifiers of any 

65 applicable service level agreements). A packet is classified 
by loading its user_priority field 114, ToS fields 202 and/or 
DS field 220 with a particular value or codepoint. Similarly, 
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an "un-trusted device" is an end station or server which is 614 or may change these values as desired. The traffic types 

not assumed to correctly classify its own packets and/or and DS codepoints for a given template arc preferably 

maintain its flow of traffic within all applicable traffic derived from empirical studies and analysis of the computer 

specifiers. Packets from an un-trusted device must be exam- network operations and usages of such industries and orga- 

ined and reclassified as necessary. Additionally, the flow 5 nizations. 

from un-trusted devices must be policed. In a similar In order to select the desired template and enter the 
manner, the ports of an intermediate device that are coupled requested information, the network administrator may inter- 
to one or more un-trusted devices are referred to as "un- act with various windows of a graphical user interface 
trusted ports", whereas ports coupled to only trusted devices (GUI). These windows, for example, may present fields, 
are "trusted ports". 10 such as the entries for columns 616 and 618, having pull- 
Once the QoS domains have been defined, the network down menus that request information from the network 
administrator preferably proceeds to select the high-level, administrator. The information may be entered by the net- 
device-independent traffic management policies that are to work administrator using a mouse or keyboard in a conven- 
be implemented within each domain. First, the network ll0nal manner " ^ m ^ rface > m ? K ?™\ 15 P«^"bly 
administrator selects an overall traffic template that estab- 15 *J mJar * °P eratlOQ /° ?f Cisco Works Windows interface 
lishes the different traffic types that are fo be supported for ™Jg™8 router interfaces) ^or the VlanDirectormter- 
.... rt oj ■ i -1 »u * i face of the Cisco Works for Switched Intemetworks(CWSl) 
within the respective QoS domain In particular the network interface (for CO[lfi m VLANs), both from Cisco 
administrator may select one of several available traffic Systems Inc 

templates. An exemplary traffic template may be the traffic lt ^ bft understood that Qlher means of ^ sochxing 

type list established by the IEEE in the 802.1p standard, 20 tfaffic lQ applications and DS codepoints, 

which defines the following traffic types: best effort, besides traffic templates, may be employed. It should also be 

background, excellent effort, controlled load, video, voice un d er stood that network administrators may select different 

and network control, as described above. Other traffic tern- traffic tcmp i ates or adjust their parameters for different times 

plates include a financial template, a manufacturing template 0 f day or for emergency situations, 

and a university or education template. 25 Next, the network administrator defines any location- 

HG. 6 is a highly schematic representation of a financial specific policies. For example, the network administrator 

template 610 for use by a network administrator in accor- may specify that intermediate devices located at the border 

dance with the present invention. As shown, the financial of the QoS domain should only accept traffic that belongs to 

template 610 includes a first column 612 listing a plurality a specific group, such a company employees, department 

of available traffic types corresponding to the financial 30 members, etc. Any traffic which does not belong to the group 

template 610. The available traffic types include best effort, should be dropped. The network administrator may also 

background, CEO best effort, voice, business applications, define one or more lists of global parameters that are to be 

stock exchange applications, 500 kb/s video conference, 2 utilized throughout the QoS domain. An example of a global 

Mb/s video conference and network control. A second parameter list is a prioritized list of queue scheduling 

column 614 identifies a particular differentiated service (DS) 35 algorithms from first choice to last choice, such as WFQ, 

value corresponding to each traffic type. The DS codepoint WRR and Priority Queuing (PQ). Other examples of global 

establishes the overall treatment that is to be assigned to the parameter lists include congestion algorithms (e.g., RED 

corresponding traffic type within the respective QoS domain over tail dropping), enabling multi-link Point-to-Point Pro- 

302. To fit within the first six bits of DS field 220, DS tocol (PPP) fragmentation, if available, and enabling Virtual 

codepoints are in the range of 0-63. As described below, the 40 Circuit (VC) merging, if available. 

DS codepoints may also be used by intermediate devices in Associated with the template 610 are one or more data 

loading the user_priority and/or ToS fields 114, 202 with structures and, as information is entered into the template 

corresponding values during classification. 610, these data structures are preferably updated accord- 

A third column 616 identifies the network users who may ingly. As described below, these data structures are used to 

take advantage of the various traffic types. For example, the 45 generate the traffic management rules implemented by the 

network administrator may decide that any network user . intermediate devices. FIGS. 7A-7E are block diagrams of 

may utilize the best effort, background, voice, 500 kb/s exemplary data structures associated with template 610. In 

video, 2 Mb/s video and network control traffic types. particular, FIG. 7A is a network user table 710 that maps 

However, only the chief executive officer (CEO) may take users identified in column 616 of template 610 with actual 

advantage of the CEO best effort traffic type and only so user names and/or IP addresses and masks. User table 710 

network users from the marketing, administrative, preferably includes a user column 712, a name column 714, 

executive, financial analysis and financial planning depart- an IP address column 716, an IP mask column 718 and a 

ments may utilize the business applications traffic type. plurality of rows such that the intersection of a column and 

Similarly, only network users from the financial analysis, row defines a table entry. As information is entered in 

financial planning and trading departments may use the 55 column 616 of template 610, corresponding entries are made 

stock exchange applications traffic type. A fourth column in the user column 712 of table 710. As described below, 

618 identifies the application programs corresponding to information for columns 714, 716 and 718 is subsequently 

each traffic type. For example, available business applica- added by the policy server 322. FIG. 7B is an application 

lions may include a spreadsheet application, a word proces- table 730 that maps the applications programs entered on the 

sor application, or any of the well-known and commercially 60 financial template 610 to their network protocol, such as the 

available business applications from SAP AG of Walldorf, Transmission Control Protocol (TCP) or User Datagram 

German or PeopleSoft, Inc. of Pleasanton, Calif. A stock Protocol (UDP) port numbers. In particular, application 

exchange application may be TIB from TIBCO Inc. of Palo table 730 preferably includes a first column 732 listing the 

Alto, Calif. The identification of network users in column application programs identified in the selected template 610 

616 and the application programs in column 618 are pref- 65 and a second column 734 that identifies both the transport 

erably entered by the network administrator. The network protocol and the port number for each corresponding appli- 

administrator may rely on default DS codepoints in column cation program. 
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FIG. 7C is a classifier table 740 that maps DS codepoints, 
including these specified by the network administrator in the 
selected template 610, with corresponding values for use in 
classifying or shaping traffic within the corresponding QoS 
domain 302, as described herein. In particular, each avail- 
able DS codepoint (0-63), which is loaded in a first column 
742, is preferably mapped to a DS mark down value 
contained in a second column 744, a User Priority value 
contained in a third column 746 and a Type of Service (ToS) 
value contained in a fourth column 748. Preferably, table 
740 is preconfigured with a set of default values correspond- 
ing to the selected template 610. The network administrator 
may, however, access table 740 while establishing the high 
level policies and modify these values. 

FIGS. 7D-E are exemplary queue/threshold assignment 
tables that map DS codepoints to queues and thresholds 
depending on the number of queues and thresholds that are 
available at a given interface. For example, FIG. 7D is a first 
queue/threshold assignment table 760 for an interface sup- 
porting two queues and two thresholds per queue. As shown, 
table 760 includes a column 762, 764 for each queue and a 
row 766, 768 for each threshold. At the intersection of each 
column and row is cell 770a-o* that contains the set of DS 
codepoints for the corresponding queue/threshold combina- 
tion. For example, cell 770a identifies the set of DS code- 
points (e.g., 0, 4, 8, etc.) to be assigned queue 1 and 
threshold 1. Similarly, cell 770J identifies the set of DS 
codepoints (e.g., 3, 7, 11, 62, 63, etc.) to be assigned queue 
2 and threshold 2. FIG, 7E is a second queue/threshold 
assignment table 774 for an interface supporting 2 queues 
and 4 thresholds. Accordingly, table 774 includes two col- 
umns 776, 778 (one for each queue) and four rows 780-783 
(one for each threshold) whose intersections define a plu- 
rality of cells 784a-/i. The cells 784a-A contain the set of DS 
codepoints for the corresponding queue/threshold combina- 
tion. 

FIG. 7F illustrates a third queue/threshold assignment 
table 788 for interfaces supporting 5 queues and 2 thresh- 
olds. Thus, table 788 includes 5 columns 790-794 and 2 
rows 795, 796 whose intersections define a plurality of cells 
798a-;. As described above, each cell 798«-; includes a set 
of DS codepoiots for the corresponding queue/threshold 
combination. For example, cell 798a includes DS code- 
points 0, 10, etc., while cell 798g includes DS codepoints 6, 
19, 60, etc. 

It should be understood that a queue/threshold assignment 
is preferably generated for each number of queue/threshold 
combinations supported by the interfaces in the network. 

It should be further understood that tables 760, 774 and 
788 may only assign a subset of DS codepoints to queues 
and thresholds, rather than all DS codepoints. For example, 
DS codepoints may be segregated into standardized and 
private classes or codepoints. Standardized codepoints are 
assigned particular per hop behaviors by the IETF such as 
expedited or assured forwarding. Private codepoints may be 
associated with any treatment on an implementation-by- 
implementation basis. The present invention preferably 
maintains the associated behaviors of any standardized 
codepoints. 

Generation of Policy Rules Based on the Selected High- 
Level Policies 

Referring to FIG. 4, these high-level policies, including 
the financial template 610 (FIG. 6), data structures 710, 730, 
740, 760, 774 and 788 (FIGS. 7A-F) and location-specific 
policies, if any, are then provided to the policy server 322. 
In particular, the information is received at the policy 



translator component 410, as shown by arrow 420. Policy 
translator 410 examines the high-level policies and corre- 
sponding data structures and may perform certain initial 
processing. For example, to the extent the user table 710 lists 
5 individual or group network users by title or department, the 
policy translator 410 may identify the actual users and 
obtain their IP addresses and/or corresponding subnet 
masks. For example, by accessing the repository 326 and/or 
other information resources, such as DHCP server 329, the 
1Q policy translator 410 may enter additional information in 
table 710. In particular, the policy translator 410 may query 
the repository 326 or DHCP server 329 to obtain the CEO's 
name, IP address and IP mask. This information may then be 
inserted in the corresponding entries of user table 710. 
15 Similar information, where appropriate, may be obtained for 
groups, such as the marketing, administrative and executive 
departments, from repository 326 or DHCP server 329, and 
entered into user table 710. The policy translator 410 may 
employ a conventional database query-response application 
20 such as SQL and the Light weight Directory Access Protocol 
(LDAP) to communicate with the repository 326 and DHCP 
server 329. Alternatively, the policy translator 410 may be 
pre-configured with such information. 
The information for column 732 of the application table 
25 730 may also be obtained and inserted by the policy trans- 
lator 410. In particular, policy translator 410 may include a 
database that correlates application programs to transport 
protocol and port number. Many applications, such as the 
hyper text transport protocol (HTTP), are assigned specific, 
3 q fixed TCP/UDP port numbers, such as port 80, in accordance 
with Request for Comments (RFC) 1700. This information 
may be stored by the policy translator 410 in a conventional 
manner. Although RFC 1700 provides fixed port numbers 
for hundreds of applications, there are still many applica- 
35 lions that do not have predefined, fixed port numbers. The 
port numbers utilized by these application are typically 
selected dynamically by the instances of the application 
program executing at the sending and receiving devices at 
the time the respective communication session is estab- 
lished. 

To identify these dynamically selected port numbers, the 
intermediate devices may perform a stateful inspection of 
received packets for any given communication session. This 
stateful inspection will reveal the port numbers selected by 
45 the corresponding entities. Asuitable method for performing 
such stateful inspections is the Context Based Access Con- 
trol feature of the Internetwork Operating System (IOS) 
from Cisco Systems, Inc. For some application programs, 
corresponding software modules may exist for identifying 
50 the selected port numbers for any given session of that 
application program. For example, software module 
@h245.voice.inspect is used to identify the port numbers 
selected by instances of H323.voice applications. Policy 
translator 410 may be configured with the identity of these 
55 modules for insertion in the appropriate entry of application 
table 710. 

It should be understood that these data structures (e.g., 
tables 710, 730, 740, 760, 774 and 788) may be stored by 
policy translator 410 at its storage devices 412a-412c. It 
60 should be further understood that the policy generator 410 
may also generate and store additional data structures in 
response to the high-level policies selected by the network 
administrator. 

As tables 710, 730, 740, 760, 774 and 788 are loaded 
65 and/or up-dated, the policy rule generating engine 414 
accesses this information and creates one or more rules that 
can be transmitted to the intermediate devices within the 



40 
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respective QoS domain 302. These rules, moreover, which 
may include one or more access control lists, are in a format 
that is both readable and executable by the intermediate 
devices, as described below. 

First, the policy rule generating engine 414 creates a set 
of classification rules. Classification rules are generally 
utilized by intermediate devices to assign a given treatment 
to network traffic based on certain criteria, such as source or 
destination address, protocol, port number, application 
program, etc. In the preferred embodiment, classification 10 
rules, which include one or more objects, are applied at 
specific locations (e.g., an interface or group of interfaces 
coupled to un-trusted devices) or at intermediate devices 
located at the boundary of the QoS domain 302. Location- ___ _ 

specific classification rules preferably have the following ^ formatof a location-independent behavioral rule is as fol- 
format: l ows _ 



Next, the policy rule generating engine 414 creates a set 
of behavioral rules, which are utilized to instruct interme- 
diate devices how to treat data traffic assigned a particular 
DS codepoint and/or QoS label by the classification rules. 
Behavioral rules also include one or more objects and arc 
preferably applied at all compliant intermediate devices 
within the QoS domain 302. Behavioral rules may be 
location-specific or location-independent. The preferred for- 
mat of a location-specific behavioral rule is as follows. 

<loca tionxdiie ctio n xlabe l_Tes L><B ehav ioral Rule _Deciiioii> 

where the 'label_Tesr object may be <dsc_Tesl> (e.g., DS 
codepoint=N, where N is some number, such as "32") or 
<QoS_Label_Test> (e.g., QoS Label=N). The preferred 



<locftiion><clirection><acl><rino><CIftasification_Decision^ 
Rute> 

where, the "location" object identifies a particular interface, 
interface type or role as described below, the "direction 1 ' 
object refers to whether the rule is to be applied to packets 
at the input, output or both portions of the interface(s), the 
"access control list" (acl) object contains a list of criteria 
statements to be applied to the packets and the "rule man- 
agement object" (rmo) instructs the intermediate device how 
to respond if conflicting actions are returned and the 
"Classincation_Decision_Rule" object is the actual rule or 
rules being implemented to packets matching the acl object. 
Although the rmo preferably instructs the intermediate 
device to select the best match, other tie-breaking solutions 
may be presented. The second format of a classification rule, 
which is used with intermediate devices located at the 
boundary of the QoS domain 302, appears as follows. 

<acl><nno><aassification_Decision_Rule> 

In addition, the acl object may have one of two formats. 

(1) <destination IP address or destination IP maskxsource 
IP address or source IP maskxprotocolxsource and/or 
destination port numbers> or 

(2) destination or source MAC address> 

In the preferred embodiment, classification rules are used 
for one of three primary purposes: (1) assigning a DS 
codepoint to packets, (2) assigning a QoS label to packets 
while they are processed within an intermediate device or 

(3) instructing an intermediate device to shape, mark and/or 
drop oul-of-profile traffic. For example, a classification rule 
may be used at the border intermediate devices instructing 
them to drop packets with a given source IP address or IP 
mask. A classification rule may also be used to assign a given 
DS codepoint to all traffic associated with a given IP mask 
(e.g., all traffic from the marketing department) or all traffic 
associated with a given port (e.g., port 23 for Telnet). 

As described above, only sixty-four DS codepoints are 
supported by the DS field 220. To extend the concept of 
packet-specific differentiated services beyond sixty-four 
options, the present invention also utilizes Quality of Ser- 
vice (QoS) labels. A QoS label is a name string of any length 
(e.g., an integer, an alphanumeric string, etc.) that may be 
associated with a packet while it remains internal to the 
intermediate device. Classification rules may also be used to 
assign QoS labels to packets based on their source or 
destination address, protocol, application, etc. As described 
below, intermediate devices maintain a mapping of QoS 
labels to traffic types and to the corresponding action to be 
taken or service to be provided. 
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By applying the label_Test to each packet, the interme- 
diate device determines whether the corresponding 
Behavioral_Rule_Decision should be applied. The 
Behavioral_Rule_Decision object preferably implements 
25 one or more of five possible decisions: select queue, select 
queue threshold, set the User_Priority field 114, set the IPP 
sub-field 210 or shape, mark and/or drop packets satisfying 
the label_Test object. For example, a behavioral rule may 
instruct the intermediate devices to set to "6" both the 
30 User_Priority field 114 and the IPP sub-field 210 of all 
frames or packets whose DS codepoint is "61". Similarly, 
another behavioral rule may instruct intermediate devices to 
place all messages whose DS codepoint is "32" (e.g., data 
frames from a stock exchange application) in a high priority 
3S queue. Behavioral rules may similarly specify a particular 
treatment based on the QoS label, user priority or type of 
service of a packet or frame, such as fast or reliable service. 
In response, an intermediate device may select a particular 
transmission link. Since behavioral rules lack an rmo object, 
40 intermediate devices apply all behavioral rules they support, 
not just the first one. If multiple behavioral rules specify 
contradictory actions, the last one preferably lakes prece- 
dence. 

To implement traffic management policies that are inde- 
45 pendent of DS codepoints and/or QoS labels, the policy rale 
generating engine 414 preferably creates a plurality of 
configuration rules. In general, configuration rules instruct 
intermediate devices how to set-up their various traffic 
management components or mechanisms. Configuration 
50 rules also have a location-specific and location-independent 
format which are preferably as follows. 

<loca tio n ><dire ciion > <Co nfi guration_Rule_Decis ion> 

<Configuration_Rule_Decision> 

55 The "Configuration__Rule_Decision" object may be used 
to specify certain global parameters or algorithm param- 
eters. For example, the Configuration_Jlule_Decision 
object of a given configuration rule may contain a list of 
congestion algorithms in descending order of preference, 

60 such as WFQ, WRR, PQ and none. In addition, if an 
intermediate device uses tail drop and supports four different 
drop thresholds per queue, a configuration rule may set the 
four thresholds (e.g., at 50%, 80%, 95% and 100% of the 
buffer limit) and assign a name to each threshold. Similarly, 

65 if an intermediate device supports WRED, a configuration 
rule may be used to set the minimum threshold, maximum 
threshold and probability constant for each weight. Also, for 
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WRR, a configuration rule may assign the weights to the 
various queues. 

The rule generating engine 414 may also combine several 
related rules into a transaction. More specifically, rules that 
are meaningful only if applied simultaneously and which 
may cause transient misconfigurations if implemented one at 
a time, are combined into a transaction. For example, a 
network administrator may want lo log as well as drop all 
attempts to access a subnetwork or LAN by a known hacker. 
Rather than issue a separate rule that only provides for 
logging and a subsequent rule for dropping, which might 
result in transitory access by the hacker, these two rules (log 
and drop) are preferably combined into a single transaction. 
A "transaction start" object is preferably used to indicate the 
start of a set of rules forming a transaction and a "transaction 
end" object indicates the end. As described below, the rules 
and transactions arc accessible by the device-specific filter 
entity 416 which collects relevant rules for transmission to 
the intermediate devices. 

To generate the particular rules for a given QoS domain, 
the policy rule generating engine 414 preferably performs a 
conventional algorithmic transformation on the correspond- 
ing data structures (e.g., tables 710, 730, 740, 760 and 770). 
This algorithmic transformation converts the information 
from the data structures into the necessary access control list 25 
objects and classification, behavioral and configuration rule 
objects of the corresponding rules. Such algorithmic trans- 
formations are well-known to those skilled in the art. The 
objects comprising the various rules, including the rule 
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mines that router 318 has five queues 530a-530e per inter- 
face 532. Additionally, traffic management controller 512 
may determine that each queue 530o-530e may support 
either RED or tail dropping and supports two settable 
thresholds per queue. The traffic management controller 512 
may further identify the roles assigned to one or more of its 
interfaces. 

Roles preferably specify the type or nature of an interface 
or sub-interface. For example, an interface may be trusted or 
un-tmsted. It may configured to perform policing and shap- 
ing of traffic from a subscribing network. It may be a 
backbone interface and thus multiplex large volumes of 
traffic to the backbone network or it may be a QoS border 
interface. An interface may also have more than one role. 
The particular role or roles of an interface are preferably 
assigned by a network administrator utilizing a management 
protocol, such as Simple Network Management Protocol 
(SNMP) or CiscoWorks from Cisco Systems, Inc., during 
configuration of the interface. A corresponding flag, label or 
name may be maintained by the device to identify the 
various roles of its interfaces. For router 318, the interface 
coupled to domain 304 may be assigned the role of policing 
and shaping traffic from subscribing domain 304 in accor- 
dance with one or more traffic specifiers. 

The assignment of roles facilitates the creation and imple- 
mentation of network policies. In particular, global policies 
may be defined that apply to all interfaces regardless of their 
particular roles. Local policies apply to the role at one 
specific interface. In other words, policies may be assigned 
to roles and roles may be assigned to the various interfaces 



objects themselves, may be defined using Abstract Syntax 30 in the network. Thus, by simply changing the role at a given 



Notation One (ASN.l) which is well-known to those skilled 
in the art. 

The policy translator 410 also interfaces with the policy 
validation tool (PVT) 413 to identify any conflicting poli- 
cies. That is, the PVT 413 examines the high-level policies 
and performs a conflict check. In particular, the PVT 413 
determines whether the policies ascribe conflicting treat- 
ments to the same traffic. For example, two polices may call 
for different shaping or marking to be applied to the same 
traffic stream. Another policy may be incomplete by failing 
to specify a requisite condition. All conflicts detected by the 
PVT 413 are reported to the policy translator 410. The PVT 
413 may also determine whether sufficient network 
resources exist to implement the policies. For example, a 
policy may require at least one network path having 3 or 
more queues at each intermediate device along the path. If 
no such path exists, the PVT 413 preferably reports this 
condition to the policy translator 410. 

Propagation of the Policy Rules to Intermediate Devices 

In operation, intermediate devices within a QoS domain 
will request traffic management information from the local 
policy server. This information will then be utilized by the 
intermediate devices in setting their resources and in making 
traffic management decisions. In the preferred embodiment, 
the policy server and intermediate devices utilize an exten- 
sion to the Common Open Policy Service (COPS) client- 
server communication protocol. In particular, the policy 
server and the intermediate devices preferably utilize the 
COPS extension described in COPS Usage for Differenti- 
ated Services, an Internet Draft Document, dated August 
1998, from the Network Working Group of the IETF, which 
is hereby incorporated by reference in its entirety. 

More specifically, referring to FIGS. 4 and 5, upon 
initialization of router 318, the traffic management controller 
512 polls the various components and mechanisms to deter- 
mine what network resources and services router 318 has to 
offer. For example, traffic management controller 512 deter- 
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interface, a network administrator ensures that the appro- 
priate network policies are automatically propagated to and 
implemented by that interface. Each role, moreover, may 
have a corresponding precedence to resolve any conflicts 
that might arise at an interface assigned more than one role. 

All of this information may be transmitted by the traffic 
management controller 512 to the communication engine 
510 along with an instruction to send to the information to 
the policy server 322. In response, the communication 
engine 510 preferably formulates a Configuration Request 
message that includes the information received from the 
traffic management controller 512 as a series of objects. The 
Configuration Request message is then transmitted by the 
communication engine 510 to the policy server 322. 

At the policy server 322, the Configuration Request 
message is received at the corresponding communication 
engine 418 and handed to the device-specific filter entity 
416, The device-specific filter entity 416 examines the 
Configuration Request to determine what types of network 
resources and services are available at router 318 and what 
roles if any are associated with its interfaces. In particular, 
the device-specific filter entity 416 determines that router 
318 supports both RED and tail dropping, has five queues 
with two settable thresholds per queue and an interface 
whose role is to police and shape traffic from a subscribing 
network. Based on this determination, the device-specific 
filter entity 416 obtains a particular set of transactions and/or 
rules from the policy rule generating engine 414 that cor- 
responds to the network services and resources available at 
router 318. For example, the device-specific filter entity 416 
may obtain one or more classification rules instructing router 
318 to classify packets from a given source (e.g., domain 
304) with a given DS codepoint and/or QoS label. Rules for 
policing and shaping traffic from domain 304 may also be 
obtained. 

Additionally, the device-specific filter entity 416 may 
obtain one or more behavioral rules that instruct router 318 
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to map packets with various DS codepoints to specific 
queues and thresholds in accordance with the information 
contained in table 788 (FIG. 7F). More specifically, a first 
behavioral rule may provide for mapping packets with a DS 
codepoint of 0, 10, etc. (e.g., DS codepoints corresponding 
to cell 798a) to queue 1 (e.g., queue 530a) and the lower 
threshold. Another behavioral rule may map packets with a 
DS codepoint of 6, 19, 60, etc. (e.g., DS codepoints corre- 
sponding to cell 798g) to queue 2 (e.g., queue 5306) and the 
second threshold and so on. Thus, a set of behavioral rules 
are obtained that will allow router 318 to map various 
packets based on their DS codepoints to queues 530a-530e 
and corresponding thresholds. 

Filter entity 416 may also obtain one or more configura- 
tion rules. For example, filter entity 416 may obtain a 
configuration rule for use in setting the scheduler 522. In 
particular, a configuration rule may provide a list of sched- 
uling algorithms in a preferred order (e.g., WFQ, WRR and 
Priority Queuing). Another configuration rule may provide 
that Virtual Circuit merging should be applied where avail- 
able. Filter entity 416 may access the policy rules via a 
virtual information store, such as the Policy Information 
Base (PIB) specified in the draft COPS Usage for Differen- 
tiated Services document. 

Once the device -specific filter entity 416 has obtained a 
set of transactions or rules for router 318, it provides them 
to the communication engine 418 which, in turn, loads them 
into one or more Decision Messages. These Decision Mes- 
sages are then transmitted by communication engine 418 to 
router 318. Communication engine 510 at router 318 
receives the Decision Messages, extracts the rules contained 
therein and provides them to the traffic management con- 
troller 512 where they may be decoded by policy rule 
decoder 541. Traffic management controller 512 may also 
build one or more data structures (such as tables) to store the 
mappings contained in any received behavioral rules. 

It should be understood that intermediate devices leam of 
the identity of the policy server 322 through any conven- 
tional means, such as manual configuration or a device 
configuration protocol. 

Implementation of the Policy Rules at Specific Interme- 
diate Devices 

First, traffic management controller 512 proceeds to con- 
figure its components and mechanisms in accordance with 
the instructions contained in the classification rules. For 
example, to the extent router 318 supports Virtual Circuit 
merging, this feature is enabled. Similarly, to the extent 
scheduler 522 can implement WRR and Priority Queuing, 
traffic management controller 512 configures it to use WRR. 
As packets are received at router 318, they are examined by 
the packet/frame classifier 516 which reports the contents of 
the packet's User_Priority field 114, IPP sub-field 210 
and/or DS field 220 to the traffic management controller 512. 
Packet/frame classifier 516 may also supply other packet 
header information to the traffic management controller, 
such as source IP address, port, protocol, etc. In response, 
the traffic management controller 512 relies on the received 
behavioral rules to determine in which queue 530a-530<» the 
corresponding packet should be placed for forwarding and to 
instruct the queue selector/mapping entity 520 accordingly. 
Similarly, router 318 relies on the behavioral rules to deter- 
mine which packets to mark down and/or drop. 

Furthermore, to the extent router 318 policies traffic 
received from subscribing domain 304, additional configu- 
ration rules may be provided to router 318 for setting its 
traffic conditioner entity 518. For example, one or more 
configuration rules may instruct router 318 to activate its 
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meter entity 524 so as to monitor the traffic arriving from 
domain 304. If out-of-profile traffic is to be marked through 
marker entity 526, classification rules may be provided for 
re-setting the DS codepoints of traffic that is out-of-profile 
based on the information contained in table 740. 
Alternatively, if out-of-profile traffic is to be shaped or 
dropped, other configuration rules may instruct the associ- 
ated traffic management controller 512 to set the shapcr/ 
dropper entity 528 accordingly. 

This process is similarly repeated at each of the interme- 
diate devices within the QoS domain 302 that are compliant 
with the present invention. Depending on the particular 
network resources and services available at each intermedi- 
ate device, a different set of rules will be selected by the 
device-specific filter entity 416. For example, switch 306 
may similarly send a Configuration Request message to 
policy server 322 and receive a Decision Message. 
Furthermore, based on the information contained in the 
Configuration Request message from switch 306, including 
the fact that switch 306 is coupled to one or more un-trusted 
devices, such as end stations 332-336, the device-specific 
filter entity 416 may obtain one or more classification rules 
for classifying traffic received from these un-trusted devices. 
However, since switch 306 may not operate at the network 
layer, filter entity 416 may obtain classification rules for 
setting the User_Priority field 114 of packets or frames 
received on ports coupled to devices 332-336, depending on 
various parameters of the packets or frames, such as port 
number, protocol type, etc. Filter entity 416 may also obtain 
behavioral rules instructing switch 306 how to handle pack- 
ets based on the user priority value rather than DS codepoint, 
since switch 306 may not be DS-compliant. Alternatively, 
policy server 322 may provide one or more classification 
rules that map User Priority values to DS codepoints so that 
switch 306 may apply one or more behavioral rules that are 
dependent on DS codepoints to packets that have a User 
Priority value. 

It should also be understood that less than all of the 
intermediate devices within a given network may be con- 
figured to implement the present invention, although in the 
preferred embodiment, all of the intermediate devices will 
be so configured. 

The foregoing description has been directed to specific 
embodiments of this invention. II will be apparent, however, 
that other variations and modifications may be made to the 
described embodiments, with the attainment of some or all 
of their advantages. For example, other client-server com- 
munications protocols, besides COPS, may be utilized by 
the policy server and intermediate devices. In addition, the 
present invention may also be utilized with other network 
layer protocols, such as IPv6, whose addresses are 128 bits 
long. The present invention may also be used to classify 
other fields of data messages, such as the User Priority field 
of the Inter-Switch Link (ISL) mechanism from Cisco 
Systems, Inc. Therefore, it is the object of the appended 
claims to cover all such variations and modifications as 
come within the true spirit and scope of the invention. 
What is claimed is: 

1. A method for implementing high-level, device- 
independent traffic management policies within a computer 
network having multiple, dissimilar intermediate network 
devices, the method comprising the steps of: 
selecting one or more high-level policies; 
translating the one or more high-level policies into a 

plurality of executable rules; 
receiving a request for traffic management policies from 
an intermediate device supporting a set of network 
services; 
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selecting, in response to the request, one or more rules that 
are compatible with the network services supported by 
the intermediate device; 

forwarding the selected one or more rules to the interme- 
diate device; and 

utilizing the one or more rules to configure the set of 
network services at the intermediate device to reali2e 
the selected high-level policies. 

2. The method of claim 1 wherein the rules formulated by 
the step of translating include at least one of classification, 
behavioral and configuration rules. 

3. The method of claim 2 wherein the step of selecting 
further includes the step of selecting a predefined traffic 
template and loading the selected template with user and 
application information. 

4. The method of claim 3 further comprising the step of 
up-dating one or more data structures associated with the 
selected template as user and application information is 
inserted therein. 

5. The method of claim 4 wherein at least one classifica- 
tion rule includes an access control list object, a rule 
management object and a classification decision rule object. 

6. The method of claim 5 wherein the at least one 
classification rule further includes a location object and a 
direction object. 

7. The method of claim 6 wherein at least one behavioral 
rule includes a label test object and a behavioral rule object. 

8. The method of claim 7 wherein the at least one 
behavioral rule further includes a location object and a 
direction object. 

9. The method of claim 8 wherein at least one configu- 
ration rule includes a configuration rule object. 

10. The method of claim 9 wherein the at least one 
configuration rule further includes a location object and a 
direction object. 

11. The method of claim 10 wherein the step of translating 
includes the step of performing an algorithmic transforma- 
tion on the one or more data structures to obtain the 
corresponding classification, behavioral and configuration 
rules. 

12. A policy server for use in implementing high-level, 
device-independent traffic management policies within a 
computer network having multiple, dissimilar intermediate 
network devices and one or more information resources, the 
policy server comprising: 



10 



15 



20 



25 



30 



35 



40 



means for receiving the high-level traffic management 
policies including one or more corresponding data 
structures; 

a policy translator that is configured to access the one or 
more information resources for inserting information in 
the data structures; 

a policy rule generating engine coupled to the policy 
generator and configured to translate the data structures 
into one or more executable traffic management rules; 

a device -specific filter entity coupled to the policy rule 
generating engine and configured to select a subset of 
the one or more traffic management rules in response to 
a request from a respective intermediate network 
device having particular traffic management resources 
and services; and 

and a communication engine coupled to the device- 
specific filter entity for exchanging requests from inter- 
mediate network devices and selected subsets of the 
one or more traffic management rules. 

13. The policy server of claim 12 wherein the one or more 
corresponding data structures include a user table that maps 
individual network users identified in the high-level polices 
to network addresses and maps network groups to network 
masks. 

14. The policy server of claim 13 wherein the one or more 
corresponding data structures further include an application 
tabic that maps application programs identified in the high- 
level policies to network protocol and port number. 

15. The policy server of claim 14 wherein the high-level 
traffic management policies are represented by a selected 
traffic template that maps each of a plurality of traffic types 
defined by the selected traffic template with at least one of 
a differentiated service (DS) codepoint, a network user and 
an application program. 

16. The policy server of claim 15 wherein the one or more 
corresponding data structures further include a queue assign- 
ment table that maps DS codepoints to queue numbers. 

17. The policy server of claim 16 wherein the one or more 
corresponding data structures further include a queue thresh- 
old table that maps DS codepoints to queue thresholds. 

18. The policy server of claim 17 wherein the one or more 
corresponding data structures further include apriority table 
that maps DS codepoints to DS mark down values, user 
priority values and type of service values. 
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ABSTRACT 



An improved partial packet filter (10) for filtering data 
packets (210) in a computer network (12) wherein a candi- 
date field (413) of the data packet (210) is hashed to a 
plurality of bit- wise subsets (636) each being an independent 
representation of the candidate field (413). Each of the 
bit-wise subsets (636) is compared to a reference hash table 
(644) which has been prepared in a preliminary operation 
series (514). The preliminary operation series (512) config- 
ures a plurality of target fields (714) to set selected memory 
locations (312) in the reference hash table (644). 



17 Claims, 4 Drawing Sheets 



Receive Packet l I 12 
Operation j 1 """ 

7^ 



210 



I Extract Candidate 
I Field Operation 



414 



413' — r 



. 219 



— 



Candidate Field 
Reduction Operation 



626, 



639 



630 



, ! Subset Selection 
| | Operation j 




04/30/2003, EAST Version: 1.03.0002 



U.S. Patent 



Dec. 5, 199S Sheet 1 of 4 



5,473,607 



Network 



12 



Node 
18 



r 



Fig. 1 

~ i 



Target 
Memory 

16 



10 



Controller 
14 



Fig. 2 



1 


Host 


-£ 

1 


Processor 


20 


J 





210 



212 



216 



220 

( 

) 



7 v- 

/ 219 
214 



218 



226 



222 



04/30/2003, EAST Version: 1.03.0002 



U.S. Patent Dec. 5, 1995 Sheet 2 of 4 5,473,607 



Fig. 3 



312 



312 



312 



312 



312 



312 



312 



310 



422 



410 



Fig. 4 (prior art) 



414 



416 



Reject 
Packet 



Receive 
Packet 




Extract 
Candidate 
Field 




413 



418 



Match 



420 



Forward 
Packet 



04/30/2003, EAST Version: 1.03.0002 



U.S. Patent Dec. 5, 1995 Sheet 3 of 4 5,473,607 



Fig. 5 



Preliminary 
Operation Series 

512 



Packet Processing 
Operation Series 

514 



Fig. 6 

Receive Packet 
Operation 



412 




210 



Extract Candidate 
Field Operation 



414 



413- 



219 



Candidate Field 
Reduction Operation 



^626 




628 



639 



Subset Selection 
Operation 



630 , 

i 



636a \L,' 

Hash Matrix 



642 




Reference Hash 
Table 



all match 



Packet Forwarding 
Operation 



.646 



04/30/2003, EAST Version: 1.03.0002 



U.S. Patent 



512 

\ 



Dec. 5, 1995 Sheet 4 of 4 

Fig. 7 



5,473,607 



Target Field 
Selection 



714a 




714b 




"712 



714c 



Bit-Wise Subset 
Quantity 
Determination 



718 




716 



Target Field 
Reduction 



728a- 




739 




Target 


Subset 


Selection 


Operation 



736ab 



736aa 




644- 



7 

736ba 




^ ( 




730 | 

J 

736ca 

736cb 



N 



Target Memory 
Setting 



312a 



\ 

736bb 740 



o j o j i |olo|olo'o|o|o[o|o|OfVo |oloT o 



312d x 



3J2 



04/30/2003, EAST Version: 1.03.0002 



5,473 

1 

PACKET FILTERING FOR DATA 
NETWORKS 

TECHNICAL FIELD 

5 

The present invention relates generally to the field of 
computer science and more particularly to data networking 
and component devices attached to data networks. 

BACKGROUND ART , 0 

Computer networks are becoming increasingly common 
in industry, education and the public sector. The media over 
which data are carried generally carry data in units referred 
to as "packets" which are destined for many different 
sources. Addressing and packet typing are included in most 15 
standardized and proprietary packet based networking pro- 
tocols which make use of destination address fields at the 
beginning of and/or within each data packet for the purpose 
of distinguishing proper recipient(s) of the data of the 
packets. As a packet is received at intermediate and end 20 
components in a system, rapid determination of the proper 
recipient (s) for the data must be made in order to efficiently 
accept, forward, or discard the data packet. Such determi- 
nations are made based upon the above discussed address, 
packet type and/or other fields within the relevant packets. 23 
These determinations can be made by network controller 
hardware alone, by a combination of hardware and software, 
or by software alone. In broadcast type networks, every node 
is responsible for examining every packet and accepting 
those "of interest", while rejecting all others. This is called 30 
"packet filtering". Accuracy, speed and economy of the 
filtering mechanism are all of importance. 

When the above discussed detenninations are made 
through a combination of hardware and software, the hard- 33 
ware is said to have accomplished a "partial filtering" of the 
incoming packet stream. It should be noted that one type of 
packet filtering is accomplished on the basis of packet error 
characteristics such as collision fragments known as "runts", 
frame check sequence errors, and the like. The type of w 
filtering relevant to the present discussion is based upon 
packet filtering in which filtering criteria can be expressed as 
simple Boolean functions of data fields within the packet as 
opposed to filtering based upon detection of errors or 
improperly formed packets. 45 

In the simplest case, each node of a computer network 
must capture those packets whose destination address field 
matches the node's unique address. However there fre- 
quently occur situations in which additional packets are also 
of interest. One example occurs when the node belongs to a 50 
predefined set of nodes all of which simultaneously receive 
certain specific "groupcast" packets which are addressed to 
that group. Groupcast packets are usually identified by some 
variation of the address field of the packet. Groupcast 
address types generally fall into one of two forms. "Broad- 55 
cast" addresses are intended for all nodes and "multicast" 
addresses are targeted for specific applications to which 
subsets of nodes are registered. Another case of such field- 
based packet filtering occurs when certain network manage- 
ment nodes are adapted to focus on specific protocols, ^ 
inter-node transactions, or the like, to the exclusion of all 
other traffic. 

Attachment of a networked device to the network is 
realized through a "controller" which operates indepen- 
dently of the host processor. Packet filtering then occurs in 65 
two successive stages beginning at the controller, which 
examines packets in real-time. To accomplish this, the 
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controller is "conditioned" with an appropriate subset of the 
specified filtering criteria, according 10 the filtering capa- 
bilities of that controller, The controller classifies packets 
into three categories: Those not satisfying the filter criteria 
("rejects"); those satisfying the criteria ("exact matches"); 
and those possibly satisfying the criteria ("partial matches"). 
Rejects are not delivered to the processor. Those packets 
which are classified as exact or as possible matches are 
delivered, with appropriate indications of their classifica- 
tion, to the device processor. The controller, ideally, 
excludes as many unwanted packets as its capabilities will 
allow, and the host processor (with the appropriate software 
operating therein) completes the overall filtering operation, 
as required. The value of filtering packets at the controller 
level (the partial filtering) is that it reduces the burden on the 
host processor. 

Controller filtering implementations are constrained by 
the fact that they must process packets in real -lime with 
packet reception. This places a high value on filtering 
mechanisms that can be implemented with a minimum 
amount of logic and memory. Controller based filtering 
criteria are contained in a target memory. In the case of exact 
matching, a literal list of desired targets is stored in the target 
memory. While exact matching provides essentially perfect 
filtering, it can be used in applications wherein there are only 
a very small number of targets. 

Partial filtering is employed when the potential number of 
targets is relatively large, such as is often the case in 
multicast applications. A primary consideration is the "effi- 
ciency" of the partial filter. Efficiency (E), in this context, 
may be expressed as: 

E=Tn/Pn 

where: 

Tn=the number of target packets of interest; and 
Pn=the number of potential candidates delivered to the 
processor. 

An efficiency of E=1.0 represents an exact filtering effi- 
ciency wherein every candidate is a desired target. This is 
the efficiency of the filtering which occurs in the "exact 
matching" previously discussed herein. While exact filtering 
efficiency is an objective, the previously mentioned con- 
straints, including that the controller must do its filtering in 
essentially real-time, will generally not allow for such 
efficiency. 

The predominant method used in the prior art for partial 
packet filtering is "hashing". The process conventionally 
begins with the extraction from each received packet of all 
fields involved in the specified filtering criteria. The com- 
posite of such relevant fields is called the "candidate field". 
Assuming an even distribution of candidate fields (a situa- 
tion that is not always literally accurate, but the assumption 
of which is useful for purposes of analysis), there will be a 
potential number of packet candidates of 2 ch where Cb is the 
number of bits in the candidate field. The hashing function 
produces a reduction in the bit size of the candidate field 
according to a "hashing function". Asa pan of the initiation 
of the controller, the hashing function is applied to each field 
of the target memory to assign a "target hash value" to each 
such field. The controller memory is initialized as a bit mask 
representing the set of target hash values. Then, during 
operation, a "candidate hash value" is created by applying 
the hashing function to each candidate field. The candidate 
hash value is used as a bit index into the controller memory, 
with a match indicating a possible candidate. 

As can be appreciated in light of the above discussion and 
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from a general understanding of simple hashing operations* 
the hashing function has the effect of partitioning the 2 cb 
candidate possibilities into Mb groups (called "buckets"), 
where Mb is the number of bits in the controller's target 
memory. Because candidate packets that fall into the same 5 
bucket are not distinguished, a "hit" represents any of 
2 C( VMb candidates. Useful hashing functions will partition 
the candidate possibilities in a roughly uniform distribution 
across the set of Mb buckets. For a single target, the 
efficiency of such a hashing method is Mb/2" If Tn desired to 
targets arc represented by Bn buckets (where BrK=Tn and 
Bn<=Mb, the efficiency of such a hashing method is: 

E=Tn/(Bnl cb Mb)=TnMbfBn2 Cb 

In exact matching, target memory could hold Mb/Cb 
targets. Hashing is appropriate when the number of buckets 
(Bn) is larger than this figure. However, effective hashing 
also requires thai the number of buckets be less than Mb, 
because as target memory density increases there is less 2Q 
differentiation among candidate fields. With the target 
memory full of hash targets, Bn=Mb and the efficiency is 
Tn/2°\ 

As can be appreciated, the described prior art hashing 
method used for partial packet filtering implies a loss of M 
information in that a single hash value potentially represents 
a large set of candidates. Clearly, it would be desirable to 
reduce such loss of data. Correspondingly, it would desirable 
to maximize the filtering efficiency for a given Mb or (or to 
minimize the Mb for a given filter efficiency). 3{J 

To the inventor's knowledge, no prior art method for 
partial packet filtering has improved efficiency or reduced 
data loss as compared to the conventional hashing method 
described above. 

DISCLOSURE OF INVENTION 35 

Accordingly, it is an object of the present invention to 
provide a method and means for efficiently performing a 
partial filtering operation on data packets in a computer 
network. 40 

It is another object of the present invention to provide a 
method and means for partial packet filtering which rejects 
a maximum number of incoming packets which are not at 
interest without requiring a large target memory and without 
unduly slowing down the processing of incoming packets. 45 

It is still another object of the present invention to provide 
a partial packet filtering method and means which is inex- 
pensive to implement. 

It is yet another object of the present invention to provide 50 
a partial packet filtering method and means which will 
operate in real-lime or near real-time. 

It is still another object of the present invention to provide 
a partial packet filtering method and means which is adapt- 
able to a variety of network system requirements. 55 

Briefly, the preferred embodiment of the present invention 
implements multiple independent hashing functions applied 
in parallel to the candidate field of each packet. The com- 
bined application of multiple independent hashing functions 
results in specification of a hash matrix, with each coordi- 60 
nate of the hash matrix being the result of one of the hashing 
functions. The hash matrix includes the results of different 
hashing algorithms applied to a single candidate field, or the 
same hashing function applied to different subsets of the 
candidate field, or a combination thereof. The filter param- 65 
eters consist of the set of acceptable result values for each 
hashing operation. 
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An advantage of the present invention is that partial 
packet filtering efficiency is improved, thereby freeing the 
host processor from a substantial portion of the packet 
filtering operation. 

Yet another advantage of the present invention is that 
filtering efficiency is increased geometrically with an 
increase in target memory. 

Still another advantage of the present invention is that a 
minimum amount of target memory is required for a specific 
target efficiency. 

Yet another advantage of the present invention is that the 
panial packet filtering can be performed in a minimum 
amount of time for a given target efficiency. 

These and other objects and advantages of the present 
invention will become clear to those skilled in the art in view 
of the description of the best presently known modes of 
carrying out the invention and the industrial applicability of 
the preferred embodiments as described herein and as illus- 
trated in the several figures of the drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

FIG. 1 is a block diagram depicting a portion of a 
computer network with an improved partial packet filter 
according to the present invention in place therein; 

FIG. 2 is a diagrammatic representation of a conventional 
prior art Ethernet data packet; 
FIG. 3 is diagrammatic representation of a hash table; 
FIG. 4 is a flow chart showing a conventional prior art 
partial packet filtering operation; 

FIG. 5 is a block depiction of a partial packet filtering 
method according to the present invention; 

FIG. 6 is a flow chart, similar to the chart of FIG. 4, 
depicting the packet processing operation series of FIG. 5; 
and 

FIG. 7 is a flow chart depicting the preliminary operation 
series of FIG. 5. 

BEST MODE FOR CARRYING OUT 
INVENTION 

The best presently known mode for carrying out the 
invention is a partial packet filter for implementation in a 
personal computer resident Ethernet controller. The pre- 
dominant expected usage of the inventive improved packet 
filter is in the interconnection of computer devices, particu- 
larly in network environments where there are relatively few 
targets. 

The improved partial packet filter of the presently pre- 
ferred embodiment of the present invention is illustrated in 
a block diagram in FIG. 1 and is designated therein by the 
reference character 10. In the diagram of FIG. 1, the 
improved partial packet filter 10 is shown configured as part 
of a network system 12 (only a portion of which is shown in 
the view of FIG. 1). In many respects, the best presently 
known embodiment 10 of the present invention is structur- 
ally not unlike conventional partial packet filter mecha- 
nisms. Like prior art conventional partial packet filters, the 
best presently known embodiment 10 of the present inven- 
tion has a controller 14 with an associated target memory 16. 
In the example of FIG. 1, the improved partial packet filter 
10 receives data from a network node 18 and performs the 
inventive improved packet filtering process on such data 
before passing selected portions of the data on to a host 
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processor 18 to which the improved partial packet filter 10 
is dedicated. 

FIG. 2 is a diagrammatic representation of a conventional 
Ethernet data packet 210. The standardized Ethernet packet 
210 has a preamble 212 which is 64 bits in length, a 3 
destination address 214 which is 48 bits in length, a source 
address 216 which is 48 bits in length, a length/type field 218 
which is 16 bits in length and a data field 220 which is 
variable in length from a minimum of 46 eight bit bytes to 
a maximum of 1500 bytes. Following the data field 220 in 10 
the packet 210 is a 4 byte (32 bit) frame sequence check 
("PCS") 222. The packet 210 is transmitted serially begin- 
ning at a **head" 224 and ending at a "tail" 226 thereof. The 
preamble 212, destination address 214, source address 216 
and lengthAype field 218 are collectively referred to as the 15 
header 219. 

FIG. 3 is a diagrammatic representation of a conventional 
single dimensional hash table 310 with which one skilled in 
the art will be familiar. The hash table 310 has a plurality of 
address locations 312 each of which can be "set" (set to 1) 20 
or left unset (set to zero). 

FIG. 4 is a flow diagram depicting the operation of a 
conventional prior art partial packet filtering operation 410. 
As previously discussed briefly, a packet 210 (FIG. 2) is ^ 
received (receive packet operation 412) from the network 18 
(FIG. 1) and a candidate field 413 (such as the header 219 
of the packet 210) is extracted (extract candidate field 
operation 414). A hashing operation 416 is performed on the 
extracted candidate field 413 to produce a bash value 417 JQ 
and the hash value 417 is compared to the hash table 310 
(FIG. 3) stored in the target memory 16 (FIG. 1) in a 
comparison operation 418. If the result of the comparison 
operation 418 is a match, the packet 210 is forwarded in a 
forward packet operation 420. If the resul t of the comparison 35 
operation 418 is not a match, the packet 210 is rejected 422 
in a reject packet operation. It should be remembered that 
the use of the header 219 here is an example only, and any 
portion or combined portions of the packet 210 might 
constitute the candidate field 413 in a given application. w 

FIG. 5 is a flow diagram depicting the inventive improved 
packet filtering process 510. The improved packet filtering 
process 510 is accomplished in a preliminary operation 
series 512 and a packet processing operation 514, each of 
which is repeated as required, as will be discussed herein- 45 
after. The preliminary operation series 512 is accomplished 
according to software residing in the host processor 20 (FIG. 
1) to configure the target memory 16 (FIG. 1) as will be 
discussed hereinafter. It should be noted that the fact that the 
improved packet filtering process 510 is divided into the two J0 
main operation categories (the preliminary operation series 
512 and the packet processing operation 514) does not 
distinguish this invention over the prior art. Rather, the 
processes within the preliminary operation series 512 and 
the packet processing operation 514 describe the essence of 55 
the inventive process. 

FIG. 6 is a flow chart showing the inventive packet 
processing operation 514 in a manner analogous to the 
presentation of the prior an partial packet filtering operation 
410 depicted in FIG. 4. As can be seen in the view of FIG. 60 
6, the packet processing operation series 514 is similar in 
many respects to the prior art partial packet filtering process 
410 (FIG. 4). In the packet processing operation scries 514, 
a packet 210 (FIG. 2) is received (receive packet operation 
412) and a candidate field 413 is extracted in an extract 65 
candidate field operation 414. In the best presently known 
embodiment 10 of the present invention, the inventive 



packet processing operation series 514 next performs a 
candidate field reduction operation 626. In the best presently 
known embodiment 10 of the present invention, the candi- 
date field reduction operation 626 is merely the application 
of the conventional CRC polynomial algorithm to the can- 
didate field 413 to yield a 32 bit CRC output value 628 
(although any of a number of similar algorithms might be 
applied for this purpose). Next, a subset selection operation 
630 selects a predetermined number (two in the example of 
FIG. 6) of bit-wise subsets 636 from the CRC output value 
628. The method for determining the quantity of bit-wise 
subsets 636 to be selected in the subset selection operation 
630, and the size of each, will be discussed hereinafter. In the 
best presently known embodiment 10 of the present inven- 
tion, the bit-wise subsets 636 are each 6 bits in length. It 
should be noted that, in the best presently known embodi- 
ment 10 of the present invention, the bit- wise subsets 636 
are selected from the CRC output value 628 simply by 
taking the first 6 bits of the CRC output value 628, the 
second six bits, and so on until as many bit- wise subsets as 
are needed are obtained and so, in the best presently known 
embodiment 10 of the present invention, the bit wise subset 
636 are "consecutive bit section " of the fixed size field (the 
CRC output value 628 in the best presently known embodi- 
ment 10 of the present invention. The inventors have deter- 
mined that the bits of the CRC output value 628 (resulting 
from the CRC polynomial function) are independent of each 
other, and so any 6 bit portion of the CRC output value 628 
is as representative of the CRC output value 628 as is any 
other 6 bit portion. 

The bit-wise subsets 636 are then compared to the hash 
table 310 (FIG. 3) stored in the target memory 16 (FIG. 1) 
in a comparison operation 642. The combined multiple hash 
values 636 may be considered to be a hash matrix 638 (in the 
example of FIG. 6, a two dimensional hash matrix 638). 

It is important to note that the essence of the present 
inventive method lies in the extraction of the plurality of 
independent or relatively independent representative indices 
of the candidate field 413 ("candidate filled indices") which, 
in the example of the best presently known embodiment 10 
of the present invention are the bit- wise subsets 636 which 
make up the hash matrix 638. That is, the bit-wise subsets 
636 are representative fields in that the bit- wise subsets 636 
are representative of the candidate field 413, as discussed 
above. The generally simultaneous (parallel) processing of 
these is the source of the advantages of the present inventive 
method and means. The exact method described herein in 
relation to the best presently known embodiment 10 of the 
present invention, that of first reducing the candidate field 
413 in the candidate field reduction operation 626 and then 
extracting the bit-wise subsets 636 is but one of many 
potential methods for accomplishing such a parallel hashing 
operation 639, and the present invention is not intended to 
be limited by this aspect of the best presently known 
embodiment 10. 

In the best presently known embodiment 10 of the present 
invention, in a comparison operation 642, each of the 
bit-wise subsets 636 is compared to a reference hash table 
644 (a "target hash array") stored in the target memory 16 
(FIG. 1) and only if all match is the packet 210 forwarded 
in a packet forwarding operation 646. In the example of FIG. 
6, the reference hash table 644 will be a 64 element array 
representing all values from 0 through 63 inclusive. Some 
elements of the reference hash table 644 are set as will be 
discussed hereinafter in relation to the preliminary operation 
series 512. If the value of the bit-wise subset "falls into one 
of the buckets" (is equivalent to a corresponding set bit in 
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the reference hash lable 644), then the data packet 210 is 
defined as being a "match". 

Now returning to a consideration of the preliminary 
operation series 512 (FIG. 5) with an understanding of the 
packet processing operation series 514, the target memory 
16 is configured in process steps much like those described 
in relation to the packet processing operation series 514 of 
FIG. 6. 

FIG. 7 is a Row diagram of the preliminary operation 
series 512 according to the best, presently known embodi- 
ment 10 of the present invention. A preliminary operation 
which is common to both the prior an and the present 
invention is a target field(s) selection process 712. The target 
(field) s selection process is merely the selection of criteria 
to which incoming packets 210 are to be compared. For 
example, if the entire process is to be on the basis of desired 
destinations, then an intended destination address 214 (FIG. 
2) will be (one of) the target field(s) 714, and if three 
destinations are of interest, then there will be three target 
fields 714 as illustrated in the example of FIG. 7. The actual 
process involved in selecting the target field(s) is a function 
of network control software which is found in the prior art 
and which is not relevant to the present invention except to 
the extent that it delivers the target field(s) 714 to the 
inventive preliminary operation series 512. 

Having determined the quantity of target fields 714 of 
interest, host software will next determine a bit-wise subset 
quantity 716 (the appropriate "subset quantity" of bit- wise 
subset 636) in a bit- wise subset quantity determination 
operation 718. The bit- wise subset quantity determination 
operation 718 will be discussed in more detail hereinafter, as 
it can be better understood in light of the present description 
of the entire preliminary operation series 512. For the 
present simplified example of FIGS. 6 and 7, and as already 
mentioned, the bit-wise subset quantity 716 is two. That is, 
two of the bit- wise subsets 636 are to be extracted from the 
CRC output value 628 in the subset selection operation 630 
of FIG. 6. 

As can be appreciated, the target fields 714 are each 
equivalent in form to the candidate fields 413 discussed 
previously herein, and processing of the target fields 714 is 
much the same as has been previously described herein in 
relation to the candidate fields 413. In the inventive prelimi- 
nary operation scries 512, each of the target fields 714 is 
processed in a target field reduction operation 726 by 
application of the CRC polynomial to produce a target CRC 
value 728. Each of the target CRC values 728 is then 
processed in a target subset selection operation 730 to 
produce a plurality {two for each target CRC value 728 for 
a total of six, in the present example) of target bit-wise 
subsets 736. In more general terms, each of the "target fields 
714 (having been selected according to prior art methods as 
discussed previously, herein) is processed as described to 
produce a '*iarget representative field" (the target CRC value 
728 in the present example), which is then further processed 
as described to produce the "target indices", which target 
indices may be "target string subsets38 of the target repre- 
sentative field and which are, in the present example, the 
target bit-wise subsets 736. This process is alike to the 
process which is repeated as necessary to process each 
incoming data packet 210, wherein the candidate fields 413 
are processed to produce a candidate representative field (the 
CRC output value 628 in the present example), which is 
further processed to produce the "candidate string subsets" 
(the bit-wise subsets 636 in the present example). The 
quantity of target bit-wise subsets 736 taken from each target 
CRC value 728 is also the bit-wise subset quantity 716 (two, 
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in the present example). It should be noted that a target 
parallel hashing operation 739 is like the previously 
described parallel hashing operation 639 in that the inven- 
tion might be practiced with variations of the specific steps 
therein which are presented here as features of the best 
presently known embodiment 10 of the present invention. 

In a target memory setting operation 740 the reference 
hash table 644 is formatted such that each memory location 
312 corresponding to a value of any of the target bit-wise 

( subsets 736 is set. For example, if the first target bit-wise 
subset 736a were "000010" (decimal value 2) then the third 
memory location 312c in the reference hash table 644 would 
be set to "1", as is illustrated in FIG. 7. As can be appreciated 
from the above discussion, the maximum number of 

, memory locations 312 in the reference hash table 644 which 
can be set by this process is the quantity of target bit-wise 
subsets 736 (six, in the present example). However, since 
two or more of the target bit-wise subsets might coinciden- 
tally hash to the same value, a lesser quantity of memory 

j locations 312 might also be set. 

Now returning to a more detailed discussion of the 
bit-wise subset quantity determination operation 718, the 
target memory 16 is to be configured to maximize the 
effectiveness of the filtering based on the quantity of mul- 

; ticast packets 210 of interest to the software of the host 
processor Therefore, the bit-wise subset quantity determi- 
nation operation 718 attempts to determine (or, at least, to 
approximate) an optimal number of indices per packet (and, 
thus, the bit-wise subset quantity 716 discussed previously 

a herein). The "optimal" number here means that which will 
minimize the number of "uninteresting" packets which 
match the set data bits 312 in the reference hash table 644 
while matching all of the "interesting" packets 210. In the 
best presently known embodiment 10 of the present inven- 

5 tion, the following table is used to determine the bit- wise 
subset quantity 716. 
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TABLE OF SUBSET QUANTITIES 


Addrcitcs of 
Iniercsi 


Number of Huh Indices 
Bit- Wise Subset Quantity 7)6 


1-2 


5 


3 


4 


4-9 


3 


10-16 


2 


17 or more 


1 



The above table is offered here as a guide only, in that the 

50 "optimal" number of selected hash indices may vary in ways 
not presently contemplated. Furthermore, it should be noted 
that the above table is based upon an assumption that none 
of the target indices (the target bitwise subsets 736 in the 
best presently known embodiment 10 of the present inven- 

5j tion hash to the same memory locations 312 in the reference 
hash table 644. If, indeed, two or more of the target bit-wise 
subsets 736 did hash to the same memory location 312, then 
additional hash indices could be added to increase efficiency 
without sacrificing speed or requiring additional memory or 

w processing. 

It should be noted that while the packet processing 
operation series 514 is accomplished in the hardware of the 
best presently known embodiment 10 of the present inven- 
tion, the preliminary operation series (which can be accom- 

65 plished at a more leisurely pace) is performed primarily by 
software of the host processor 20. As can be appreciated in 
light of the above discussion, the preliminary operation 
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series will be repeated when the network 12 is reconfigured, 
when it is desired to communicate with additional members 
of the network 12, or upon other occasions according to the 
needs of the user and the network 12. The packet processing 
operation series 514 will be repealed whenever an incoming 5 
packet is detected from the network node 18. 

It should also be noted that, while the best presently 
known embodiment 10 of the present invention hashes each 
of the CRC values 628 and 728 to a common reference hash 
table 644, the invention might be practiced with equal 10 
efficiency by hashing each of the CRC values 628 and 728 
to its own individual hash table (not shown). Using the 
quantities of the example of FIGS. 6 and 7, each of the 
individual hash tables would be 32 bits (memory locations 
312) large (one half of 64 bits, since it must be divided 15 
between the two target CRC values 728). The individual 
bit-wise subsets 636 and 736 would then be 5 bits long 
(decimal value 0 through 31). 

Various modifications may be made to the inventive 
improved packet filter 10 without altering its value or scope. 
For example, the quantity, size, and derivation of the plu- 
rality of bit-wise subsets 636 and 738 could readily be 
revised according to the parameters discussed herein. 

All of the above are only some of the examples of 25 
available embodiments of the present invention. Those 
skilled in the art will readily observe that numerous other 
modifications and alterations may be made without depart- 
ing from the spirit and scope of the invention. Accordingly, 
the above disclosure is not intended as limiting and the 3(J 
appended claims are to be interpreted as encompassing the 
entire scope of the invention. 



20 



INDUSTRIAL APPLICABILITY 



35 



The improved partial packet filter 10 is adapted to be 
widely used in computer network communications. The 
predominant current usages are for the interconnection of 
computers and computer peripheral devices within networks 
and for the interconnection of several computer networks. 40 

The improved partial packet filters 10 of the present 
invention may be utilized in any application wherein con- 
ventional computer interconnection devices are used. A 
significant area of improvement is in the inclusion of the 
parallel processing of a plurality of indices (bit-wise subsets 45 
636) of a packet 

The efficiency of the filtering provided by the improved 
partial packet filter 10 is significantly improved, particularly 
for cases where the number of targets is smalt relative to the 
number of "buckets" (memory locations 312). To compare 
the efficiency of the present inventive improved packet 
filtering process 510 embodied in the improved partial 
packet filter 10 with the prior art partial packet filtering 
process 410, assume, for example, the following values: 

Mb=64 (representing 64 memory locations 312 in the 
reference hash table 644) 

Cb=48 (representing a 48 bit candidate field 413 size — a 
typical size of the destination address 214 

Drt=4 (representing a bit-wise subset quantity 716 of four) 60 

Then, the prior art partial packet filtering process 410 will 
partition the 2 a> possibilities among 64 distinct buckets, one 
of which matches the bucket into which the single target 
falls. In the improved packet filtering process 510, the four 
parallel hashing functions partition among 16 possible buck- 63 
ets each. The efficiency (Ef) for the prior art partial packet 
filtering process 410 would then be: 
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The efficiency (Ef4) for this example of the improved 
packet filtering process 510 is: 

£y*=*4"/(4 4 *2 4, )=Vi u 

The efficiency Ef4 is better than the efficiency Ef by a 
factor of 2'° (1024), which is to say that only a thousandth 
as many (uninteresting) packets will be delivered to the next 
stage of filtering using the inventive improved partial packet 
filter 10 as compared to the prior art. 

Filtering of packets may be accomplished through a 
combination of exact and partial match filters. Typically, one 
or more partial filterings will occur first, with the multiple 
dimensions of each filtering accomplished in parallel with 
each other (according to the present invention). Packets 
which pass through the inventive improved partial packet 
filter 10 may then be filtered using an exact match filter 
technique, Buch as "binary search lookup" of the filter data 
in a sorted table of acceptable filter data values. Further- 
more, results of partial filtering can be used to determine 
which of many (possibly sorted) tables in which to search for 
the packet 

Accordingly, the inventive improved packet filtering pro- 
cess 510 may be applied more than once to each incoming 
packet 210 (in a first stage and a second stage). In such an 
example, configuration of the first stage partial filtering 
would involve specification of the number and type of 
hashing operations to be performed, along with the portion 
of the packet which is to comprise the filter data for each 
such operation, along with acceptable results for each. 
Multiple partial filterings may be configured with the speci- 
fication including the logical relation to apply to the results 
of each filtering. For example, partial filtering A might be to 
apply the 32 bit CRC polynomial to the destination address 
field of an Ethernet packet, and retain the lowest order 3 
bits — a value from 0 to 7. Partial filtering B might be to 
apply the 32 bit CRC polynomial to the source address field 
of the Ethernet packet, and retain the lowest order 3 bits. The 
logical relation might be to accept packets only for which the 
results of the first filtering (A) is either 2 or 4, and the result 
of the second filtering (B) is either a 3 or a 4. In a general 
case, one may expect the likelihood of arbitrarily filter data 
to "pass" the first filtering to be 2 in 8 (25%), since 2 of the 
8 values from 0 to 7 arc acceptable. Similarly, the likelihood 
of the second filtering "passing" such a filter is 2 in 8 (25%). 
Assuming that the two filterings arc, as desired, truly inde- 
pendent, the likelihood of this arbitrary packet being 
accepted is the product of these, or 1 in 16. Note further that 
the specification of these "acceptable result sets" ({2,4} for 
A and {3,4} for B) requires 16 bits of information for full 
specification, where 8 bits indicate the acceptability/unac- 
ceptability of each of the 8 possible values of filtering A, and 
8 additional bits indicate the acceptability/unacceptability of 
each of the 8 possible values of filtering B. Use of such 
multiple partial filterings may be especially effective in 
situations where filtering criteria are derived from indepen- 
dent portions of the filter data, such as filtering for all 
packets whose destination address OR whose source address 
is within a set of interesting addresses AND whose packet 
type indicates a particular protocol of interest. 

Since the improved partial packet filters of the present 
invention may be readily constructed and are compatible 
with existing computer equipment it is expected that they 
will be acceptable in the industry as substitutes for conven- 
tional means and methods presently employed for partial 
packet filtering. For these and other reasons, it is expected 
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thai the utility and industrial applicability of the invention 
will be both significant in scope and long-lasting in duration. 
We claim: 

1. A method for selectively forwarding a data packet and 
controlling the distribution of data packets in a computer 5 
network system, the data packet having a candidate field 
containing information about the data packet, the method 
comprising: 

configuring a target memory of a controller to contain a 
target hash array in steps including; 10 
aa determining a target field and extracting a plurality 

of target indices from said target field, the target 

indices being a binary number having a value; 
ab setting memory locations in the target memory 

corresponding to the value of each of the target 15 

indices; and 
processing the data packet in steps including: 
ba extracting the candidate field from the data packet; 
bb extracting from the candidate field a plurality of 

candidate field indices; 
be comparing the values of each of the candidate field 

indices to the target hash array; and 
bd forwarding the packet when each of the values of 

each or the candidate field indices corresponds to a 

memory location of the target hash array which was 

set in step ab. 

2. The method of claim 1, wherein: 

step aa is accomplished in substeps including: 

aal reducing the target fields to a plurality of target JQ 

representative fields; and 
aa2 selecting one or more target string subsets from the 

target representative field; and 
step bb is accomplished in substeps including: 
bbl reducing the candidate field to a plurality of 35 

candidate representative fields; and 
bb2 selecting one or more candidate string subsets from 

the target representative field. 

3. The method of claim 1, wherein: 

step ab is accomplished by causing only those memory 40 
locations in the target memory which correspond to the 
value of each of the target string subsets to contain a 
value of one, 

4. The method of claim 2, wherein: 

step aal is accomplished by applying a cyclic redundancy 45 
check algorithm to each of the target fields; and 

step bbl is accomplished by applying the same cyclic 
redundancy check algorithm to the candidate field. 

5. The method of claim 2, wherein: 5fl 
in step aa2 the target string subsets are selected by 

extracting a plurality of target bit-wise subsets from the 
target representative field; and 
in step bb2 the candidate string subsets are selected by 



12 

extracting a plurality of candidate bit* wise subsets from 
the representative candidate field. 

6. The method of claim 2, and further including: 

an additional process step preceding step ab wherein a 
subset quantity is determined, the subset quantity being 
the number of target string subsets to be extracted from 
each of the target representative fields and also the 
number of candidate string subsets to be extracted from 
each of the candidate representative fields. 

7. The method of claim 6, wherein: 

the additional process step is accomplished, at Least ini- 
tially, by selecting the subset quantity from a table of 
subset quantities. 

8. The method of claim 2, wherein: 

each of the target representative target and the candidate 
representative field are 32 bits in length. 

9. The method of claim 1, wherein: 

steps aa through ab are repeated when a change in the 
distribution of data packets is desired. 

10. The method of claim 1. wherein: 

steps ba through bd are repeated for each incoming data 
packet. 

11. The method of claim 1, and further including: 

an additional process step preceding step ab wherein a 
subset quantity is determined, the subset quantity being 
the number of target indices to be extracted from each 
of the target fields and also the number of candidate 
indices to be extracted from each of the candidate 
fields. 

12. The method of claim 11, wherein: 

the additional process step is accomplished, ai least ini- 
tially, by selecting the subset quantity from a table of 
subset quantities appropriate to a quantity of target 
quantities. 

13. The method of claim 1, wherein: 

the candidate field includes a target address field of the 
data packet 

14. The method of claim 1, wherein: 

the data packet is a standardized Ethernet data packet. 

15. The method of claim 1, wherein: 

the target hash array is an unapportioned array such that 
each of the target indices is used to set memory 
locations in that unapportioned array. 

16. The method of claim 1, wherein; 

the target hash array is apportioned such that at least some 
of the target indices are directed to different portions of 
the target hash array. 

17. The method of claim 1, wherein: 

the target indices and the candidate indices are each a 
binary string of fixed bit length. 

» » * * * 
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NETWORK FILTERING SYSTEM 

This is a continuation of application Ser. No. 08/888,875, 
filed Jul. 7, 1997, now U.S. Pat. No. 5,781,729; which is a 
continuation of Ser. No. 08/575,506, filed Dec. 20, 1995, 
now U.S. Pat. No. 5,793,954. 

TECHNICAL FIELD 

The present invention relates to network communications 
systems and, in particular, to improved systems and methods 
for parsing, filtering, generating and analyzing data com- 
posed of inter-related structures such as protocols found 
within network frames. 

The application includes a microfiche appendix of soft- 
ware developed applicable to the system disclosed, consiting 
of one (1) slide and 84 frames. 

BACKGROUND ART 

Existing network interface devices provide systems for 
receiving, analyzing, filtering and transmitting network data 
or frames of data. Network Protocol Analyzers, Bridges, and 
Routers are among the most common oetwork interface 
devices currently available. 

Conventional network protocol analyzers provide, for a 
predefined set of network frame structures or protocols, a 
system for monitoring the activity of a network and the 
stations on it by allowing network traffic to be captured and 
stored for later analysis. Common capture and analysis 
capabilities include the gathering of statistics, subsequent 
report generation, the ability to filter frames based on 
specific criteria, and the ability to generate network traffic. 

Bridges and routers are network devices that pass frames 
from one network interface to another. Bridges operate at the 
data-link layer and routers at the network layer of the OSI 
reference model. Like protocol analyzers, both bridges and 
routers may gather statistics and filter incoming network 
frames based on specific criteria, however incoming frames 
also may be forwarded to other networks based on infor- 
mation collected by the bridge or router. Routers typically 
support only a limited number of network protocols. 

Each of these network devices requires an ability to 
separate network frames into individual protocols and their 
components (typically referred to as parsing), an ability to 
filter incoming frames based on a logical combination of one 
or more field values extracted during parsing, and an ability 
to gather statistics based in part on extracted field values. 
Typically, it is a requirement that network frames be 
received, analyzed and forwarded at full network speeds, 
sometimes on many different networks at one time. 

A frame filter consists of one or more criteria which 
specify one or more valid values for a frame (or segments of 
a frame). Frame filtering criteria are typically implemented 
using an offset (from frame or protocol header start), a length 
in bits which defines a field, a value for comparison, and 
mask values for identifying relevant and irrelevant bits 
within the field. For multiple value filter criteria, the result 
from each filter value is logically OR'ed together to obtain 
an overall result. Therefore, each additional result adds to 
the processing required to filler a given field. For filtering on 
optional protocol fields that do not occur at the same relative 
offset in each protocol frame, this method is time- 
consuming. Thus, it would be desirable to perform filtering 
on both fixed and optional variable offset fields for any 
number of values or ranges of values without incurring any 
additional overhead. 
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Parsing, the process wherein network frames are broken 
up into their individual protocols and fields, is necessary for 
filtering with offsets relative to protocol headers, gathering 
field based statistics, generating network traffic, routing data 

5 frames, verifying field values, and displaying network 
frames in human readable form. In conventional systems, 
the parsing process has an overall structure which incorpo- 
rates control logic for each supported protocol. Therefore, 
additional control logic must be developed when support for 

!0 a new protocol is added to a conventional system. As the 
development of additional control logic, whether imple- 
mented in hardware or software, may be both time consum- 
ing and expensive, it would be highly desirable to be able to 
parse all protocols with a single configurable software (or 

15 hardware) module so that support for additional protocols 
could be added to a system without requiring substantial 
modification to the system or its control logic. 

Further, although microprocessors (or CPUs) available 
today can execute tens or even hundreds of millions of 

20 instructions per second, vendors often must provide dedi- 
cated hardware assistance and/or front-end processors with 
hand-coded assembly language routines to achieve the nec- 
essary processing rates for more than one pair of networks. 
Unfortunately, this solution requires hardware and/or soft- 

25 ware modifications whenever changes are made to the 
number of supported features or protocols. 

Finally, as networks become larger and more complex, the 
maintenance of a comprehensive statistics database by each 
network device becomes more important. Because these 

30 statistics databases typically are not utilized by a maintain- 
ing device, but instead are collected by a network manage- 
ment device, the collection process may affect performance 
adversely without any corresponding benefit to the collect- 
ing device. 

35 In light of the considerations discussed above, it is 
believed that a network interface system having a config- 
urable protocol analysis capability with common control 
logic applicable to many different network devices would be 
highly desirable. 

40 

SUMMARY OF INVENTION 

The present invention is directed to improved systems and 
methods for parsing, filtering, generating and analyzing data 
(or frames of data) transmitted over a data communications 

45 network. In one particularly innovative aspect of the present 
invention, a single logic control module, which may be 
implemented in hardware or software, is utilized to perform 
any of a number of data manipulation functions (for 
example, parsing, filtering, data generation or analysis 

so functions) based upon one or more programmably config- 
urable protocol descriptions which may be stored in and 
retrieved from an associated memory. 

The use of common control logic (i.e. the use of a single 
logic control module) and programmably configurable pro- 

55 toco] descriptions allows changes to existing protocols to be 
made and support for new protocols to be added to a system 
in accordance with the present invention through configu- 
ration only — without the need for hardware and/or software 
system modifications. Thus, those skilled in the art will 

50 appreciate that a network interface in accordance with the 
present invention may be configured and reconfigured, if 
necessary, in a highly efficient and cost effective manner to 
implement numerous data manipulation functions and to 
accommodate substantial network modifications (for 

65 example, the use of different data transmission hardware, 
protocols or protocol suites) without necessitating substan- 
tial system changes. 
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In one preferred form, the system of the present invention The system of the present invention may be employed in 

may employ a CPU or other hardware implcmentable any system where it is useful to be able to examine and 

method for analyzing data from a network in response to perform various operations on contiguous bit -fie Ids in data 

selectively programmed parsing, filtering, statistics structures, wherein each data structure is composed of 

gathering, and display requests. Moreover, the system of the 5 predefined fields of one or more contiguous bits. Further, the 

present invention may be incorporated in a network device, system of the present invention is particularly efficient 

such as a network analyzer, bridge, router, or traffic where operations must be performed on a subset of included 

generator, including a CPU and a plurality of input devices, fields. 

storage devices, and output devices, wherein frames of Those skilled in the art will recognize that the system of 

network data may be received from an associated network, JQ the present invention gains a distinct advantage in size and 

stored in the storage devices, and processed by the CPU maintainability over conventional network devices by 

based upon one or more programmably configurable proto- implementing analysis capabilities for multiple known and 

col descriptions also stored in the storage devices. The unknown protocols using common control logic, 

protocol descriptions may take the form of one or more Furthermore, the system gains a distinct advantage in speed 

protocol description files for each supported network pro- and efficiency over conventional network devices when the 

tocol and may include a protocol header record and plurality 15 control logic is implemented in hardware or a front-end 

of field sub-records having data corresponding to an asso- processor, without incurring the penalty of additional hard- 

ciated protocol and fields defined therein. ware and/or software development when protocol defini- 

The system of the present invention also preferably tions change, 
includes logic for extracting field values from particular Accordingly, it is an object of the present invention to 
network frames, performing validation and error checking, 20 provide an improved system for network analysis wherein 
and making parsing decisions based upon field values and the system may determine which protocols and which pro- 
information in the programmably configurable protocol tocol fields exist in a network frame (also referred herein as 
descriptions. parsing) using common control logic combined with con- 

The system of the present invention also preferably figurable protocol descriptions, 
includes logic for filtering a subset of network frames 25 It is yet another object of the present invention to provide 
received from the input or storage devices which satisfy a an improved system for network analysis wherein the con- 
filter criteria based upon information defined in the pro- trol logic may be implemented in hardware as well as 
grammably configurable protocol descriptions. software. 

The system of the present invention also preferably It is yet another object of the present invention to provide 

includes logic for filtering network frames which satisfy a 30 an improved system for network analysis wherein each 

plurality of filter criteria which, if desired, may be joined supported analysis capability is configurable even when the 

together by Boolean operators. "f™ 1 « implemented m hardware. 

° \ , iL 4 . „. , c It is another object of the present mvention to provide an 

The system of the present invention also preferably eJ tem J for nelwo & ^ fa wberein mc s tcm 

includes logic for analyzing a filter request by breaking the ^ dctCTn ?- mc whether a particular network frame includes 

request into its component criteria lo determine whether the a field ^ satisfies a particular fflter criteria based upori 

result from evaluating a particular filter request criteria when information store d in a programmably configurable protocol 

combined with results from earlier criteria can be used to description. 

filter (Le. discard) a particular network frame. It ^ yet another ob j ect 0 f n, e present invention to provide 

The system of the present invention also preferably an improved system for network analysis wherein the sys- 

includes logic for collecting statistics based upon extracted tern may determine if a particular network frame includes a 

field values satisfying a statistics criteria based upon infor- protocol field that satisfies a particular statistics gathering 

mation defined in the programmably configurable protocol criteria defined in a programmably configurable protocol 

descriptions. description. 

The system of the present invention also preferably It is yet another object of the present invention to provide 

includes logic for determining a next protocol description 45 an improved system for network analysis wherein the sys- 

structure required to continue analyzing a network frame. tern may generate network traffic in the form of frames 

The system of the present invention also preferably constructed from selected protocol descriptions with the 

includes logic for determining a frame length and individual f 1 ^ l ° s P caf y a vanet y of memods for var y m 8 dividual 

protocol header lengths from extracted field values in a cn held values. 

network frame iU It is still another object of the present invention to provide 

" . . ■ 1 e ui an improved system for network analysis wherein the sys- 

The system of the present invention also preferably (em ^ rout / Qetwork frames (determ ine the appropriate 

includes logic for making routing decisions based upon destination interface) that satisfy a parUcuiar roming criteria 

information contained in the programmably configurable define£ , ^ & programmablv configurab ] e protocol descrip- 

protocol descriptions. 55 don whjle providing a capability to specify a variety of 

The system of the present invention also preferably methods f or varying individual field values during the 

includes logic for determining display formats based on routing process 

information contained in the programmably configurable , t ^ stU| acothcr objccl of ^ prcscnt tQ providc 

protocol descnp ions. an ^^y^ system for network analysis wherein the sys- 

Thc system of the prcscnt invention also preferably 60 tern may determine if a particular network frame includes a 

includes logic for verifying individual field values and protoco , ficld lhat mnt!linSt a vahlc related to either the 

making parsing decisions based on the validity of the value. ovcral , icngm of ^ framc or mc ajmat protocol hcadcr 

The system of the present invention also preferably length, 
includes logic for constructing and transmitting network 

frames with varying field contents based on information 65 BRIEF DESCRIPTION OF THE DRAWINGS 

contained in the programmably configurable protocol FIG. 1 is a block diagram of a network interface system 

descriptions. in accordance with one form of the present invention. 
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FIG. 2 is a diagram representing a set of data records of referred to as 10, may be implemented in a network device 

a typical network frame which may be contained in the dala including input devices 12, data storage devices 14, analysis 

files of the network interface system illustrated in FIG. 1. control logic 16 for facilitating the input, storage, retrieval, 

FIG. 3 is a diagram representing a set of data records of an d analysis of network frames, and output devices 18 for 

a protocol description in accordant with one form of the 5 forwarding frames or displaying or printing the ^results of 

F . . analyses. A data storage device 14 may include a data file 20 

presen inven ion. ^ j,^^ f rames having n protocol data records, wherein 

FIG. 4 is a diagram representing a control record of an each data rccord data io a plurality of 

Ethernet protocol description which may be utilized in a predefined fields. Protocol description files 22 also may be 

nelwork interface system in accordance with one form of the stored m tne data storage device 14. The protocol description 

present invention. gl es 22 may include a protocol control record and n field 

FIG. 4a is a diagram representing five defined field sub-records, which together may describe a subset of a 

sub-records of the Ethernet protocol description illustrated network protocol and include rules for analyzing that pro- 

in FIG. 4. tocol. 

FIGS. 4b, 4c, and 4d are diagrams representing lookup 15 The network device control logic 16 is capable of retricv- 

structures referenced in FIG. 4a fields 0, 2 and 4 respec- ing a subset of network frames from the input devices 12 or 

lively. data files 20 which satisfy one or more criteria based upon 

FIG. 5 is a diagram representing a control record of an extracted field values and filtering criteria contained in one 

imaginary Generic Protocol description which may be uti- or more of the protocol description files 22. The network 

lized in a network interface system in accordance with one ^ device control logic 16 also includes logic for determining 

form of the present invention. frame and protocol header lengths, gathering statistics, veri- 

FIG. 5a is a diagram representing eleven defined field fication and error checking, determining routes, varying 

sub-records of the GP description illustrated in FIG. 5. values, and formatting output. 

FIGS. 56, 5c, 5d, and 5e are diagrams representing lookup A Personal computer or conventional network device, 

structures referenced in FIG. 5(a) fields 1, 3, 7 and 8, 25 such as an IBM PC (or compatible), Apple Macintosh®, or 

respectively m y Unix®, or Zenix® workstation, protocol analyzer, 

FIGS. 6, 6a, and 6b are diagrams representing the control bli ?F> router > l " ffic r > or simi ! a ' s y stem ^ be 

record and field sub-record of a protocol description struc- utilized in accordance with the system of the present inven- 

ture that allows parsing of optional fields of the GP descrip- tioo. The data input devices 12 may comprise any of a 

. . mm in number of commercially available network lnterf ace devices 

tion shown in FIGS. 5-5<?. , - , . . 1 L j 

. it , , and may include a conventional keyboard or mouse it 

H ° S I'l^J are diagrams representing the control r ^ ^ data c devices M takc lfac form of 

record jmd field sub-records of a protocol descnption struc- of a of commerciaU avai]able data st 

ture that describes the End Of List option of the GP ions (such ^ RAMf RQM eprom, or various sized 

description shown in FIGS. 5-5*. fixcd dkk an(J ^ data output dcviccs lg fflay 

FIGS. 8, 8a, and 8b are diagrams representing the control CQmprisc aDy of a Dumb er of commercially available user 

rccord and field sub-records of a protocol description struc- interface devices, such as CRT displays, monitors, network 

ture that describes the No Operation option of the GP intcrface dcviccs and/or pri ntcrs (if required). The analysis 

description shown in FIGS. 5-5e. control logic 16 may be implemented as a computer program 

FIGS. 9, 9a, and 9b are diagrams representing the control ^ written in any language suitable for systems programming or 

record and field records of a protocol description file that may \> e implemented in hardware if better performance is 

describes the Maximum Frame Size option of the GP required. In one presently preferred form, the analysis 

description shown in FIGS. 5-5e control logic 16 may be implemented via the programming 

FIGS. 10, 10a, 10b, 10c, IQd and lOe are diagrams files x t forth in the attached Appendix, which is herein 

representing data records of a filter expression control and 45 incorporated by reference. However, those skilled in the art 

associated field filler structures. will appreciate that the analysis control logic 16 might 

FIG. 11 is a flow chart illustrating top level frame parsing equivalcntly be implemented in dedicated hardware using, 

control logic in accordance with one form of the present for example, one or more application specific integrated 

invention. circuits ("ASICs") or one or more field programmable gate 

FIG. 12 is a flow chart illustrating protocol parsing control 50 arrays ("FPG As"), 

logic in accordance with one form of the present invention. The network interface system 10 of the present invention 

FIG. 13 is a flow chart of the field parsing control logic is preferably implemented on a personal computer, work- 
in accordance with one form of the present invention. station or conventional network device having a 32-bit or 

FIG. 14 is a flow chart representing value verification, larger bus and register set, an optional math co-processor, at 

error checking, next protocol and branch determination 55 least one megabyte of available RAM, and for personal 

control logic in accordance with one form of the present computer and workstation applications, a fixed disk having 

invention. at least 10 megabytes of available storage space. As shown 

FIG. 15 is a flow chart representing field filtering control m mc attached Appendix, the analysis control logic 16 may 

logic in accordance with one form of the present invention. bc programmed in the C++ language, with abstract data 

FIG. 16 is a flow chart illustrating field value extraction «> for statistics gathering, value verification, next 

and varying control logic in accordance with one form of the P mtoco[ determination, filtering, varying values, checksum- 

present invention ming and route determination capabilities, and protocol 

control and field records. 

DESCRIPTION OF PREFERRED Referring now to FIG. 2, a data file 20 in accordance with 

EMBODIMENTS 65 one f onn 0 f t ne present invention may include a plurality (n) 

Referring now to FIG. 1, a network interface system in of protocol header data records and optional Data and Pad 

accordance with one form of the present invention, generally records. Each protocol record contains data organized into a 
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plurality of predefined fields. Each field comprises a collec- 
tion of 1 or more contiguous bits and includes a set of valid 
values for that field. For example, a particular protocol 
specification might include a 6 bit header length field that 
limits the protocol header length to values between 20 and 
60 inclusive, thereby excluding values less than 20 and 
values from 61 to 64. 

The number of possible contiguous bit fields for a pro- 
tocol header of length N bits where N is greater than 1 can 
be expressed by ihe following formula: 

N 

Number of Possible Field* = ^ t 



TABLE 1 



Offset Name 



PROTOCOL CONTROL RECORD 



Description 



0-3 namejength length of protocol name in bytes including 

NULL terminator 
4-7 protocol_name name of protocol control record is describing 
8-11 filename name of file control record is stored in 

12-15 numE-Us total bit length of protocol header control 

record is describing 
16-17 numFields number of fields required to describe protocol 
header 

18-19 airfield index of field currently referenced 

20-23 outFlog flag indicating template has been output to file 

24-27 dbW display bit width for protocol header display 

28-31 fields field records that describe protocol header 

32-25 options pointer to option control record to use if this 

protocol has optional fields 
36-39 Rt pointer to protocol specific routing table 



The field records referenced at bytes 28-31 in the table 
above are preferably organized as shown in Table 2: 



TABLE 2 



FIELD SUB-RECORDS 



Offset Name Description 



0-3 fplen flag indicating value is actual length of frame 

(multiplier) 
4—7 fblen length of field in bits 

8-11 fdwoff byte offset from start of protocol header of 32-bit 
field containing value 
febl number of bits to left shift 32-bit value 

fsbx number cf bits to right shift 32-bit value 

ffmt number indicating a display type {Le., decimal, 

hex, ... ) 

fiflag flag indicating value is actual length of protocol 

header (multiplier) 
reserved not used . . . pad byte to align following fields 

fmult multiplier to apply to value prior to display 



12 
13 
14 

15 

16 
17 



TABLE 2-continued 



FIELD SUB-RECORDS 



OBset Name Description 



15 



It will be appreciated by those skilled in the art that any 
possible organization of fields for any possible protocol 
specification is contemplated for the network interface sys- 
tem 10 of the present invention. 20 

Referring now to FIG. 3, a protocol description file 22 in 
accordance with one form of the present invention may 
include a protocol control record, and a plurality (n) of field 
data records. In a particularly preferred embodiment, the 
protocol control record (shown below in Table 1) may define 25 
the overall structure of a network protocol and reference 
other information relating to the network protocol. 



18 fswap flag indicating the need to swap bytes and words 

in 32-bit field containing value 

19 fsdspfield flag indicating that this field should be displayed 
20-23 fname pointer to field name (0 - none) 

24-27 ptr2statfl pointer to configured statistics 

structure/class (0 - none) 
28-31 ptr2np pointer to lookup structure/class . . . next protocol 

definition to use (0 - none) 
32-35 ptr2vary pointer to vary field value structure/class (0 - none) 
36-39 ptr2csum pointer to checksum structure/class (0 - none) 
40-43 ptr2flt pointer to filter criteria structure (0 - none) 
44-47 ptr2rte pointer to Route Table structure/class (0 - none) 



The statistics records referenced in Table 2, above, at 
bytes 24-27 are preferably organized as shown in Table 3: 



TABLE 3 



30 



35 



STATISTICS STRUCTURE/CLASS RECORD 
OSsct Name Description 

0-3 StatName pointer to user assigned name foi statistic 
4-7 Stat pointer to derived structure/class for accumulating 

configured statistic 

The next protocol lookup records referenced in the field 
sub-record table (Table 2) at bytes 28-31 are preferably 
organized as shown in Table 4: 

TABLE 4 



Offset Name 



LOOKUP STRUCTURE RECORD 
Description 



0-3 Protocol pointer to protocol description structure 
40 4-7 Next Index index of field in protocol description to parse next 

8-11 Minimum minimum acceptable value for this range 
12-15 Maximum maximum acceptable value for this range 
16-19 okbits selects even only, odd only, or all values in range 

20-23 Translation pointer to associated human language equivalent 

45 

Lookup structures can be used for determining the next 
protocol control record to use, terminating protocol process- 
ing on illegal values, branching decisions for variable length 
headers or overlapping fields, and for translation of numeric 

5 0 values to mnemonic or written language equivalents. This 
ability to specify branches on field values allows protocols 
with multiple overlapping structures to be specified and 
parsed dynamically. 
The vary field value records referenced in the field 

55 sub-record table (Table 2) at bytes 32-35 are preferably 
organized as shown in Table 5: 

TABLE 5 



60 



65 



VARY FIELD VALUE RECORD 



Offset Name Description 



0-3 mask mask for isolating field bits from 32-bit field 

4-7 nolmask mask for isolating bits not in field 
8-1 1 operand value to apply to field bits (relative to field) 
12-15 min value minimum allowable value for field bits (relative to 
field) 
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TABLE 5-continued 



TABLE 9 



VARY FIELD VALUE RECORD 
Oflset Name Description 5 

16-19 maxvalue maximum allowable value for field bits (relative to 
field) 

The checksum records referenced in the field sub-record io 
table (Table 2) at bytes 36-39 are preferably organized as 
shown in Table 6: 



TABLE 6 






CHECKSUM RECORD 


15 


Oflset 


Name 


Description 




0-3 
4-7 


verify 
compute 


pointer to routine to verify protocol checksum 
pointer to routine to compute protocol checksum 


?n 



The filter criteria records referenced in the field sub- 
record table (Table 2) at bytes 40-43 are preferably orga- 
nized as shown in Table 7: 



25 



TABLE 7 



FILTER CRITERIA RECORD 
Oflset Name Description 



0-3 Index index of this filter criteria (zero-based) 
4-7 ChPtr painter to parent filter channel 

8-11 Ranges painter to lookup structure containing all possible field 
values 

12-15 Ptl pointer to associated protocol definition for this criteria 
16-19 Fid pointer to associated field definition for this criteria 

The filter channel records referenced in the Filter Criteria 
record (Table 7) above at 4-7 are preferably organized as 
shown in Table 8: 



TABLE 8 



Offset Name 



FILTER CHANNEL RECORD 



Description 



0-3 NextCriterinlndex index of next criteria that should be applied 
to this Biter 

4—7 TotalCriteria number of criteria required to implement this 
filter 

8-11 Criteria pointer to array of Tbtalcrtteria criteria 

structures 50 
12-15 ChannelName pointer lo user supplied filter channel name 



Each configured filter consists of one or more filter 
criteria and the filter criteria may be organized into Filter 
Criteria records. The Filter Criteria records may refer 10 55 
lookup structures which allow the filter criteria to determine 
from a field value the current state of the filter expression at 
each criteria. These slates may include: PASS_FRAME 
(accept this frame) and F1LTER_FR AM E (discard this 
frame). 60 

The NextCriterialndex field referenced in Table 8 above 
at bytes 0-3 is used lo ensure that all filter expressions are 
applied in the required order. The Ptl and Fid fields at bytes 
12-19 allow filter criteria to be associated with specific 
protocols and protocol fields. The lookup records referenced 65 
in the Filter Criteria record (Table 7) at bytes 8-11 are 
preferably organized as shown in Table 9: 



FILTER LOOKUP STRUCTURE RECORD 
Offset Name Description 



Return Value PASS FRAME, FILTER FRAME value range 
result 

index of field in Filter Expression structure 
minimum acceptable value for this range 
maximum acceptable value for this range 
selects EVEN, ODD or all values in range 
pointer to associated human language equivalent 



0-3 



4-7 Index 

8-11 Minimum 

12-15 Maximum 

16-19 Mask 

20-23 Translation 



The Route Table records referenced in the Field Sub- 



organized as shown in Table 10: 



TABLE 10 







ROUTE TABLE RECORD 


Offset 


Name 


Description 


0-11 


NetMask 


mask for extracting 1 to 96 bits from protocol 






header route field 


12-15 


entries 


number of entries in Route Table 


16-19 


Table 


pointer to array of 'entries' Route Table entries 



30 



The Route Table Entry records referenced in the table 
above at bytes 16-19 are preferably organized as shown in 
Table 11: 



TABLE 11 



35 



ROUTE TABLE ENTRY RECORD 
Oflset Name Description 



40 



0-11 DstNetAddj Route Table Lookup Value (field value is 

compared with this) 
12-13 DstFrameType destination frame type (i.e., 802.3, FDDI, etc.) 
14-15 Dstlnterface destination interface number 
16-17 MacHdiLen length of MAC header and encapsulation lo 

append to frame 
18-19 DataLen length of frame less MAC header and 

encapsulation 

20-21 MinLen minimum allowable frame size for this 

destination 

22-23 MaxLen maximum allowable frame size for this 

destination 

24-27 MacHdr pointer to MAC header and encapsulation to 

append to frame 

28-31 DataPtr pointer to frame less any bits below the routing 

protocol header 



In Tables 1-11 the records of the protocol description and 
associated field, statistics, lookup, checksum, vary, route 
determination and filter records are shown as they appear 
when resident in memory. In the presently preferred 
embodiment, each of these protocol description records with 
its associated field, statistics, lookup, and filter record infor- 
mation is also written to a protocol specific protocol descrip- 
tion file (PDF). 

In the presently preferred embodiment, the following 
sequence of data is written to a PDF: 
For the Protocol Control Record: 

the length of the protocol name including NULL 
terminator, 

the name of the protocol, 

the total bit length of the protocol header, 

the number of fields required to describe records, 

the index of the field currently referenced,. 
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the display bit width, 

for each of the field records that describe the protocol 
header, 

a call is made to write the field related data 
(This sequence is described below), 
if the pointer to the option control record is NULL, zero, 

if there are options, the length of the protocol option name 
including the NULL terminator, 10 

the option name, 

the option's protocol control record 
For the Field Record: 15 



12 



TABLE 12 



30 



the flag indicating the value is the actual length of frame, 

the length of the field in bits, 

the byte offset from the start of the protocol header, 

the number of bits to left shift of the 32-bit field, 

the number of bits to right shift of the 32-bit field, 

the number indicating the display type, 

the flag indicating the value is the actual length of the 
protocol header, 

the reserved byte, 

the multiplier to apply to value prior to display, 

the flag indicating whether to byte swap the 32 -bit value, 

the flag indicating that the field is to be displayed, 

the length of the field name including the NULL 35 
terminator, or zero 

if the pointer to the statistics structure/class is NULL, zero 

if the pointer to the statistics structure/class is not NULL, 
a call is made to write the statistics type 

if the pointer to the lookup structure/class is NULL, zero 

if the pointer to the lookup structure/class is not NULL, 
a call is made to write the lookup type, the number of 
lookups, and the lookup values 
The pointer to vary field, pointer to checksum, pointer to 
filter, and pointer to route determination are handled simi- 
larly. 

in the presently preferred embodiment, the initialization 
of the system includes a determination of the presence of 
PDF files and the extraction of the protocol and associated 
control record information from all of the PDF files found. 
The number of PDF files is determined, and a ProtocolList 
is constructed consisting of a sorted vector of protocol 55 
records at least the size of the number of PDF files found. 
The name of each protocol record found is inserted in the 
ProtocolList. The PDF files are then read to memory in the 
sequence described above for the PDF file writing. The 
lookup records that indicate a next protocol are associated 
with the appropriate entries in the ProtocolList. 

Two simple protocol descriptions are provided in Tables 
12 and 13 (below) to assist in the description of the system 
of the present invention. The Ethernet Protocol specification $5 
shown below is a simplification of an actual Ethernet 
protocol header. 



ETHERNET v2.0 PROTOCOL SPECIFICATION 



0 15 23 

Destination Hardware Address 
Source Hardware Address 
Ethernet Protocol Type 
Destination Hardware Address 
address (48 bits) 
Source Hardware Address 
(48 bits) 

Ethernet Protocol Type 
(16 bits) 



destination hardware station 

source hardware station address 

upper layer protocol designator 
0x888 8-GP 



20 

The Ethernet protocol definition described above specifies 
only one possible upper level protocol, the Generic Protocol 
(GP) which is indicated by placing a hexadecimal 0x8888 
value in the protocol type field. The Generic Protocol (GP) 
25 specification shown below in Table 13 has been fabricated to 
provide examples of different types of field functionalities 
found in actual network protocols. 



TABLE 13 



GENERIC PROTOCOL (GP) SPECIFICATION 



15 



23 



31 



40 



45 



50 



Version No. 


HeaderLen 


Frame Type Frame Length 




Checksum 


Control Hop Count 




Src Socket 


Dst Socket 






Src Address 






Dst Address 




O-320 optional field bits 


Version Number ( 4 bits) 


- software version number 


HcadcrLcn 


( 4 bits) 


- length of GP header In 32 bit words. 






CM - illegal 






5 * No Optional fields, 






6-15 - 32-320 bits of options 


Frame Type 


( 8 bits) 


- upper level protocol identifier 






0 » Unknown 






1 -GP1 






2 -GP2 






3-255 - Unknown 


Frame Length 


(16 bits) 


- frame length in bytes including header 


Checksum 


(16 bits) 


- Checksum of header including options 


Control 


( 8 bits) 


- reserved (must be zero) 


Hop Count 


( 8 bits) 


- Count of number of networks traversed 


Src Socket 


(16 bits) 


- Socket of Upper-layer protocol sender 


Dst Socket 


(16 bits) 


- Socket of Upper-layer protocol 






receiver 


Src Address 


(32 bits) 


- Sender protocol address 


Dst Address 


(32 bits) 


* Receiver protocol address 



The GP options have two possible formats. Type 1 con- 
sists of a single 8-bit option type field containing an option 
type value. Type 2 contains the 8-bit option type field, but 
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also contains an 8-bit option length field to allow imple- 
mentation of variable length options in the GP. Two type 1 
options and one type 2 option defined in the GP specification 
are shown below in Table 13: 

TABLE 13 



End of Option 
List 



No Operation 



Mb Max Size 



(8 bits) 



(8 bits) 



(32/48 
bits) 



Indicates end of options list. 
Consists of an 8-bil option 
type field with value 0. 
Necessary only for list that 
does not end on 32-bit 
boundary. 

Performs no function. Consists 
of an 8-bit option type byte 
with value 1. Used for 
alignment of other GP options. 
Allows minimum and maximum 
allowable frame lengths to be 
specified. Consists of an 8- 
bit option type field with 
value 2, an 8-bit option length 
field, an 16-bit minimum frame 
length field, and an optional 
16-bit maximum frame length 
field. If the maximum frame 
length is specified, the option 
length field will have value 4, 
otherwise it will have value 6 



15 



20 



14 



TABLE 14-continued 



received (useful for bridging applications and 
interface operations) 
IntfTypes Array of values defining the type of each interface 

in the network system (useful for bridging 
operations and type specific operations) 



Network frames contain one or more protocol headers, an 
optional number of data bits, and an optional number of pad 
bits. Frame bits up to the frame length extracted during 
parsing for which no protocol description exists are consid- 
ered data. Bits beyond the frame length extracted during 
parsing are considered to be pad. Two network frames are 
provided as examples to be used during discussion of the 
control logic of the present invention: 

Frame 1 shown below has a hardware length of eighty- 
two 8-bit bytes and consists of a fourteen byte Ethernet 
header, a twenty byte GP header with no option bytes, and 
forty-eight bytes of application data. No hardware pad is 
required because the frame length exceeds the Ethernet 
minimum of sixty bytes. 



Frame (l) 



(1) 08 DO 00 00 00 03 08 00 00 00 00 04 88 88 Ethernet Header (14) 

(2) 35 00 00 44 Bl 5F 00 01 08 00 01 47 01 02 03 04 05 06 07 08 GP Header (20) 

(3) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Data (24) 

(4) 00 DO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Data (24) 



TABLE 13-contimied 



specified in units of 8-bit 4Q 
bytes. 



Describing the flow charts of FIGS. 11-16 requires the 4S 
definition of several variables. These variables (described in 
Table 14 below) are used to implement and monitor the 
current control logic state of a network interface system in 
accordance with the present invention: 

50 

TABLE 14 

FramePtr Pointer to start of network frame being parsed 

HwLen Bit length of network frame as reported by input 

device 

ParscLen Number of bits parsed in the current network frame ^5 

Current Pointer to protocol description control record in 

Protocol use 

CurField Index of field in CurrentProtocol being parsed 

ParsePtr Pointer to start of protocol header in frame being 

parsed 

FrameLen Number of meaningful bits in the current network 60 

frame 

ProloParse Number of bits parsed in the current protocol 

Len header 

HeadcrLcn Size in bits of protocol header being parsed 

ParseLvI Zero based protocol level in ISO reference model of 

protocol being parsed (current protocol) 55 
Panelist Array of pointers to protocol headers in frame 

being parsed (only 0 to (Parse Lvl-1) are valid) 
Srclntf Index of interface on which frame being parsed was 
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Frame 2 shown below has a hardware length of sixty 8-bit 
bytes and consists of a fourteen byte Ethernet header, a 
twenty -eight byte GP header including eight option bytes, 
and eighteen bytes of pad to achieve the sixty byte Ethernet 
minimum frame length requirement. 



16 



If the GetValue control logic was about to extract a value 
for the GP HeaderLen field from frame (2), ParsePtr would 
point at the first value of line 2, from FIG. 5a, fdwoff would 
be 0, fshl would be 4, and fsbr would be 28, so that 32-bits 



Frame (2) 



(1) 


08 


00 


00 


00 


00 


01 


08 


00 


00 


00 


00 


02 


88 


88 










Ethernet Header 


(14) 


(2) 


37 


03 


00 


2A 


FF 


FF 


00 


05 


08 


00 


01 


00 


01 


02 03 


04 05 


06 


07 


08 


GP Headei 


(20) 


(3) 


01 




































GP NoOp Option 


(1) 


(4) 


02 


04 


00 


00 






























GP MaxSizeOpt 


(«) 


(5) 


00 




































GP EOL Options 


(1) 


(6) 


00 


00 


00 
































GP Option Pad 


(2) 


(?) 


00 


00 


00 


00 


00 


00 


00 


00 


00 


0D 


00 


00 


00 


00 00 


00 00 


00 


00 


00 


Frame Pad 


(18) 



A flow chart is provided for each of the major control 
logic components of the present invention. The flow chart 
shown in FIG. 11 outlines ParseFrame control logic in 
accordance with the present invention and shows how 
successive protocol headers are parsed, and how remaining 
information is parsed as application data and frame pad. The 
flow chart in FIG. 12 outlines ParseProtocol control logic in 
accordance with one form of the present invention and 
shows how fixed and optional fields may be parsed in a 
selected protocol. The flow chart shown in FIG. 13 outlines 
ParseFields control logic in accordance with the present 
invention and shows how decisions are made and operations 
performed on extracted field values. The flow chart shown in 
FIG. 14 outlines Validate Value control logic in accordance 
with the present invention and shows how branching, next 
protocol determination, and validity decisions are made with 
extracted field values. The flow chart shown in FIG. outlines 
ApplyFilter control logic in accordance with one form of the 
present invention and shows how filter criteria are applied to 
fields in network frames. The flow chart shown in FIG. 16 
outlines GetValue control logic in accordance with one form 
of the present invention and shows how field values are 
extracted from network frames. These six components of the 
control logic of a network interface system in accordance 
with the present invention are described in detail below. 

Referring now to FIG. 13, a value is extracted by the 
GetValue control logic (shown in FIG. 16) of the system (at 
210) for each configured field that is relevant to the current 
network frame. As shown in FIG. 16, the fdwoff value is 
added to ParsePtr to locate and extract a 32-bit value (at 502) 
containing the field value, which is then byteswapped (at 
510) if the fswap field is TRUE. If the ptr2vary field is 
NULL (at 512 or 518), indicating that the value does not 
need to be modified or varied, the field value is extracted (at 
506) by shifting the 32-bit value left fshl bits and then right 
by fshr bits to eliminate any extraneous bits. If the ptr2vary 
field is non-NULL, the extracted 32-bit value is modified 
using the configured method (at 514 or 520) and the result- 
ing 32-bit value overwrites the extracted 32-bit value (at 516 
or 522), If the extracted value was byteswapped (at 510), the 
modified value is swapped back (at 516) prior to overwriting 
the original value. The extracted value is returned (at 508) by 
the GetValue control logic. 

It will be appreciated by those skilled in the art that the 
system of the present invention can handle different machine 
endian architectures (at 210) by rearranging the bit and byte 
order of the extracted 32-bit network frame value to match 
the target hardware architecture, and can be adapted easily 
to RISC based architectures where all memory accesses 
must be aligned in some fashion. 



of data would be extracted (at 502) and, possibly, 
2 0 byteswapped (at 510) to obtain a hexadecimal value equal to 
0x3703002A. 

In binary notation this is: 

0011 0111 0000 0011 0000 0000 0010 1010 

Shifting left 4 bits (at 506) yields: 
25 0111 0000 0011 0000 0000 0010 1010 0000 

Shifting right 28 bits (at 506) yields: 

0000 0000 0000 0000 0000 0000 0000 0111 

Which in decimal notation is: 7 

Therefore, the actual length of the GP header in frame (2) 

3Q is seven 32-bit words, which is 28 bytes or 224 bits. 

Although the presently preferred embodiment of the sys- 
tem of the present invention is designed to handle a maxi- 
mum field width of 32 bits, it will be appreciated by those 
skilled in the art that the system may be designed to handle 
any required maximum field width, and is particularly 

35 efficient where the maximum field width matches the under- 
lying hardware architecture. It will also be appreciated by 
those skilled in the art that it is possible to divide larger 
protocol fields into sub-fields as demonstrated by the Eth- 
ernet protocol field descriptions shown in FIG. 4a where the 

40 48-bit hardware address fields have each been defined as two 
24-bit sub-fields. 

The ValidateValue control logic shown in FIG. 14 is 
performed on each extracted field value by the ParseFields 
control logic (at 214) shown in FIG. 13. Each field may have 

45 an associated lookup structure reference containing one or 
more values and/or ranges of values that have a particular 
meaning for that field. 

If no lookup structure is configured for a particular field, 
all values are deemed to be valid (at 318 and 312), which 

so causes parsing to continue with the next sequentially defined 
field of the current protocol description. 

If a lookup structure exists for a particular field but the 
extracted value is not found therein (at 314 and 316), parsing 
still continues with the next defined field of the current 

55 protocol. However, the value is considered invalid. 

Values or ranges of values found in configured lookup 
structures are considered to be valid. The Prot and Nextln- 
dex values associated with a value or range found are used 
to specify NextProtocol, the protocol description (at 308) to 

60 be used after current protocol header parsing is completed, 
and the index of the next field (at 310) is used to determine 
where parsing of the current protocol will continue after the 
current field. The first valid field parsed in a protocol that 
specifies the NextProtocol has precedence over all subse- 

65 quent NextProtocol specifiers (at 306). 

The ValidateValue control logic returns an updated CurF- 
ield value (at 312 and 316) together with a valid/invalid 
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indication, and where indicated (at 308) may return an 
updated value for NextProtocol. 

Using value 0x8888 as an example, if the Validate Value 
control logic is applied to the Ethernet Type field and 
associated lookup structure shown in FIGS. 4a and 4d 
respectively, the lookup structure would be found (at 302), 
the value wUl be found in it (at 304), the associated Protocol 
field found with the range containing 0x8888 value will be 
used to update the NextProtocol variable (at 308) if it is 
NULL (at 306), and the associated Next Index field will be 
used to update the CurField variable. 

Using FIG. 5c as an example, it may be seen how values 
may be used to continue parsing at different locations in the 
current protocol description. In this case, value 0x02 for the 
Frame Type field causes Checksum field processing to be 
skipped. 

Referring back to the ParseFields control logic shown in 
FIG. 13, the ParseFields control logic parses the fields in 
each protocol header contained in a particular network frame 
by using field values obtained in accordance with informa- 
tion specified in associated protocol descriptions. The Parse- 
Fields control logic is applied for each protocol description 
required for a particular network frame. If the ParseFields 
control logic were applied to the exemplary frame, "Frame 
(1)," described above, the network interface system 10 of the 
present invention would apply the ParseFields control logic 
with the protocol descriptions for the Ethernet protocol 
shown in Table 12, the GP shown in Table 13, and an 
unspecified Data protocol description. 

The ParseFields routine is entered (at 200) with Parse Ptr 
pointing at the start of a protocol header in a particular 
network frame and CurrentProtocol set to an appropriate 
protocol description. Parsing starts at Protocol bit and field 
zero when CurField and ProtoParseLen are cleared (at 202), 
also, HeaderLen is set to the configured protocol control 
record NumBits value, and LocalProto, the local next pro- 
tocol return value variable is cleared. Using the Ethernet 
protocol description shown in FIG. 4 as an example, Head- 
erLen would be set to 112 bits. 

The control loop (at 204 through 224) continues until the 
last field has been parsed (at 206), all bits in the header have 
been parsed (at 208), or all bits in the frame have been 
parsed (at 209). 

For each field a value is retrieved by the system (at 210). 
If there is a filter criteria for the field it is applied (at 232) 
by the ApplyFilter control logic. The System Filter Status is 45 
set to FILTER_FRAME and NextCriterialndex is set to zero 
for every configured filter channel prior to the start of frame 
processing and after each frame is processed (at 124 in FIG. 
11). 

Referring now to the overall system filter channel control 
structure shown in FIG. 10, and using the filter expression 
shown below as an example: 

if {(the Ethernet Dst Vendor Address is 0x08FFFF AND 
the Ethernet Dst Station Address is 0x334455) OR (the GP 
Frame Type is 1 OR the GP Frame Type is 2)} keep this 
network frame 

we can divide the expression into three distinct filter criteria: 

(0) if the Ethernet Dst Vendor Address is 0x08FFFF 

(1) if the Ethernet Dst Station Address is 0x334455 

(2) if the GP Frame Type is 1 OR the GP Frame Type is 
2 

FIG. 10(a) shows an example Filler channel structure for 
the expression shown above and refers to the three Filter 
Criteria Records of FIG. 10(6) that implement the three filter 
criteria shown above and refer respectively to FIGS. 10(c), 
10(t/) and 10(e) which implement the three criteria as lookup 
structures. 



25 
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Referring now to FIG. 15, after the ApplyFilter control 
logic is entered (at 400), the Index of one of the filter criteria 
records shown in FIG. 10(b) is computed with NextCrite- 
rialndex (at 402 and 404) for the associated filter channel 
shown in FIG. 10(a). 

If Index is less than NextCriterialndex (at 402) it indicates 
that this filter criteria does not need to be evaluated. This 
may occur because a filter channel has been satisfied and 
NextCriterialndex has been set to TotalCriteria to disable 
further filter processing. 

If Index ts greater than NextCriterialndex (at 404) this 
indicates that a filter criteria was skipped in the evaluation 
of this filter channel which invalidates the filter result. In this 
case, further filter evaluation is disabled (at 414) by setting 
NextCriterialndex to TotalCriteria and ApplyFilter returns to 
the caller. 

If Index and NextCriterialndex are equal, the field value 
is found (at 406) in the associated lookup table, NextCrite- 
rialndex is updated with the associated Nextlndex value and 
if the associated return value status is PASS_FRAME, the 
System Filter Status is updated to PASS_FRAME. In this 
preferred embodiment, the range of possible values for a 
field must be fully covered. Similarly, in the preferred 
embodiment a frame will be completely parsed for statistics 
gathering. 

Criteria (0) cannot be used to determine a PASS/ 
FI LTER_FRAM E result for the filter expression above 
because it must be logically AND'ed with criteria (1). This 
is illustrated in FIG. lOfc, where every value results in no 
change to the status. The logical AND with criteria (1) is 
implemented using the Nextlndex value. If criteria (0) is 
FALSE then Nextlndex is 2 which causes criteria (1) to be 
skipped, otherwise Nextlndex is 1. 

Criteria (1) when TRUE can be used to determine that the 
filter expression is TRUE because it is not evaluated unless 
criteria (0) is also TRUE, and the filter expression is the 
result of ((0) and (1)) or (2). If criteria (2) is FALSE then a 
PASS/FILTER_FRAME result cannot be determined for 
the filter expression. This is illustrated by FIG. 10c, where 
the criteria value results in a PASS_FRAME status, and 
every other value results in no change to the status. The filter 
expression Count value is reset on completion of frame 
processing. 

Criteria (2) when TRUE can be used to determine that the 
filter expression is TRUE because it is logically OR'ed with 
the result of the first two criteria. 

It should be noted that the system of the present invention 
will collect statistics on all fields evaluated regardless of the 
decision to pass or filter the frame, which may not be 
acceptable in some instances. It will be appreciated by those 
skilled in the art that the system of the present invention may 
be implemented as sequential parsing loops, so that filtering 
decisions may be made prior to the application of statistics 
or other field operations. 

It will be appreciated by those skilled in the art that the 
system of the present invention offers significant advantages 
over traditional filtering methods by allowing filtering cri- 
teria to be specified for any subset of bits in any field, by 
allowing criteria to be applied to every instance of a field 
that appears more than once in a network frame, and by 
providing a simple method for easily specifying ranges of 
values. 

Returning again to FIG. 13 after applying a filter criteria, 
the extracted value is processed by the Validate Value control 
logic (at 214), which updates the NextProtocol and CurField 
variables and returns a valid/invalid value indication. If 
Validate Value returns invalid, parsing of the current field 
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stops (at 216) and restarts with the updated CurField value fields defined in FIG. 5a add up to only 160 bits, it will theo 

(at 204), otherwise each configured parsing operation is be possible to determine that the (224-160) or 64 bits of 

applied based on the extracted value. optional fields exist in frame (2). 

The statistics entity of the field sub-record may be used to For each field with a valid value, the BitLength field is 

indicate categories of statistics to be maintained for each 5 added to ProtoParseLen, the number of bits parsed in the 

protocol header field (at 218 and 236). Details about mecba- f^nt protocol, and ParseLen, the number of bits parsed in 

nisms for collecting statistics are not relevant to the present the network frame (at 222). 

discussion. However, it will be appreciated by those skilled The FrameLength field of a protocol descnpUon sub- 

in the art that the addition of various classes of statistics such rc< T° rd 7* en **** md * C ( atC ±A 

, c a . . j , value of the current field may be used to compute the length 

as field counters, summing of field contents, and arrays of 10 Qf ^ netWQrk frame ^ yalue when 

counters/sums based on field contents may be used m mu i tip Ued with the configured Frame Length value yields the 
accordance with the present invention. Using FIG. 5a as an number of meaningful bits in the clirreDl f rame ( at 240). The 
example, it would be possible to configure the FrameLength FrameLength field is configured to be 8 for the FrameLength 
field to accumulate an array of counts for each possible field ficld of mc GP description shown in FIG. 5a. If Frame- 
value. From this array, the distribution of GP frames sizes is 15 Le ng th is used together with the FrameLen value extracted 
immediately available, and the length of all GP frames and from fr ame an actual frame length of 336 bits is 
each frame size may be computed. calculated (8*42). Because the hardware length of frame (1) 
Although checksum verification/computation (at 217 and is 480 bits (8*60 bytes), it is now possible to determine that 
235) and route determination capabilities (at 219 and 237) the last ((480-366) bits) of frame (2) is pad, added to the 
are not described in detail in FIG. 13, those skilled in the art 20 frame in this case, to achieve the required Ethernet minimum 
will recognize that a system in accordance with the present length of (8*60 bytes). In a preferred form, the length 
invention may be configured easily to implement those computed for the frame is verified against the length pro- 
capabilities. Further, exemplary software listings for imple- vided by the hardware, and the minimum of the two values 
menting these capabilities are provided in the Appendix is be used as FrameLen. 

which is attached hereto and incorporated herein by refer- 25 If every field in the current protocol has been parsed (at 

ence. Moreover, upon review the listings in the Appendix 206), or every bit in the current protocol header has been 

entitled csum.asm, checksum.hpp, route.cpp and route.hpp, parsed (at 208), or every bit in the current frame has been 

those skilled in the art will appreciate that the ability to parsed (at 209), parsing of the current protocol terminates. If 

configure IP, TCP, UDP and IPX checksum capabilities may LocalProto is NULL (at 225) when parsing of the current 

readily be incorporated into a system in accordance with the 30 protocol terminates, Parse Pro to Len is added to Parse Ptr (at 

present invention. The same is true for a general purpose 16 228) so that it points to the start of the next protocol header 

bit ones complement checksum capability. Finally, those in the frame. If LocalProto is not NULL (at 225) when 

skilled in the art will appreciate that the system of the parsing of the current protocol terminates and there are 

present invention may be configured in virtually infinite unparsed header bits remaining (at 226), ParseLen and 

ways to implement virtually any desired checksum capabil- 35 ProtoParseLen are adjusted to account for each unparsed 

ity or, indeed, any desired data manipulation function. header bit (at 227) before adding ProtoParseLen to ParsePtr 

Although in the preferred form the Verify checksum (at 228). In every case, ParseFields control logic returns 

control logic is integrated into the ParseFields control logic LocalProto (at 230). 

(at 217 and 235), the result is not used because processing Referring now to FIG. 11, the ParseFrame control logic of 

of frames with bad checksums is device dependent. For 40 the present invention, network frames are composed of one 

example, frames with bad checksums would be counted and or more protocol headers which in turn are composed of one 

saved by a protocol analyzer, while a routing device would or more predefined contiguous bit fields. The ParseFrame 

count and discard them. control logic systematically parses through each network 

An ability to route frames based on values contained in frame (at 104 to 108 and 128) until all known protocol 

fields of up to 96 contiguous bits is also demonstrated in the 45 headers have been parsed. Any remaining frame bits are 

software listings included in the Appendix, and those skilled parsed as application data (at 110, 112 and 130) and/or pad 

in the art will recognize that the 96 bit limit may be changed data (at 114, 116 and 132). 

easily to allow for proper handling of protocols with route Referring now to FIG. 12, ParseProtocol control logic 

determination fields longer than 96 bits. where all fixed and optional protocol fields are parsed is 

Moreover, those skilled in the art with appreciate that the 50 entered (at 200) with ParsePtr and ParseLen initialized from 

system of the present invention may be augmented to prior processing. All protocol fields that are fixed in location 

support virtually any field based operations through modi- are parsed (at 152). If all bits in the frame are parsed (at 154) 

fication of the ParseFields control logic loop (at 204-224). after parsing fixed fields, frame parsing is complete and 

For example, it is believed that field based encryption and ParseProtocol returns NULL (at 168). If there are more bits 

decryption operations may be added to the system of the 55 in the frame to parse and the current protocol description 

present invention with minimal effort. supports optional fields (at 156) and the current frame 

The HeaderLength field of a protocol description sub- contains optional fields (at 160) they are parsed (at 160 to 

record when non-zero is used to indicate that the extracted 166) using the current protocol option control protocol 

value of the current field may be used to compute the length description as a starting point (at 158). Once all options are 

of the current protocol header. The extracted value when 60 parsed (at 172) ParseProtocol will return NULL (at 168) if 

multiplied with the configured HeaderLength field value all bits in the frame have been parsed or will return 

yields the length of the protocol header in the current LocalProto (at 170) if more bits remain to be parsed, 

network frame (at 238). The HeaderLength field is coufig- Referring again to FIG. 11, once the system has received 

ured to be 32 for the FrameLength field of the GP description a network frame (at 100), defined by an interface number 

shown in FIG. 5a. If HeaderLength is used together with the 65 (Srclntf), a frame location (FramePtr) and a hardware length 

HeaderLen value extracted from frame (2), an actual GP (HwLen), the frame is resolved into its protocol and field 

header length of 224 bits (32*7) is calculated. Because the components using the system of the present invention. 
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Using the exemplary frame, "Frame (2)," described above 
as an example, the system (at 102) in FIG. 11 would obtain 
from the receiving network interface device Srclntf, the 
receiving interface number, FramePtr, a pointer to the frame, 
and HwLen, the hardware frame length. The hardware 
length of frame (2) is 480 bits. ParseLen, the number of bits 
in the frame that have been parsed, ParscLvl and CurField, 
the index of the protocol field being processed are reset to 
zero, and CurrentProtocol, is set up with the initial protocol 
description structure of the receiving interface number 
which for frame (2) is the Ethernet Protocol description 
defined in FIGS. 4-4a\ FrameLen is set to the value of 
HwLen, and ParscPtr is set to the value of FramePtr. 

Each field in the Ethernet Protocol description as shown 
in FIG. 4a is parsed (at 106) using the ParseProtocol control 
logic shown in FIG. 13. 

The ParseProtocol control logic updates ProtoParscLen, 
the number of bits parsed in the CurrentProtocol, 
HeaderLen, the protocol header size determined during 
parsing, and returns NextProtocol, a reference to the next 
applicable protocol description structure to use during pars- 
ing. ParseProtocol also updates ParscPtr and ParseLen by 
adding ProtoParseLen to them. If NextProtocol is NULL, 
the remaining frame bits will be treated as Data and/or Pad 
bits. 

After the Ethernet protocol fields in frame (2) are parsed 
(at 106) by the ParseProtocol control logic shown in FIG. 13, 
HeaderLen, ParseLen and ProtoParseLen will be 112 bits, 
NextProtocol will refer to the GP shown in FIGS. S~S(e), 
and ParsePtr will point at the start of line 2 in frame (2). 
CurrentProtocol will be updated with the NextProtocol value 
of GP (at 130) and the GP fields in frame (2) are parsed (at 
106) by the ParseFields control logic shown in FIG. 13, 
which will update HeaderLen and ProtoParseLen to be 160 



15 



20 



25 



30 



Referring now to FIG. 13, in a preferred form the OptioD 
Type field in a frame is examined twice, once with the 
master protocol option description and once with the appro- 
priate option protocol description. If an unknown option is 
encountered (any value between 0x03 and Oxff inclusive for 
FIG. 6ft), ParseLen, ProtoParseLen, and ParsePtr are 
updated (at 227 in FIG. 13) to skip any remaining options 
and parsing of the frame continues with the LocalProto 
protocol description returned (at 230). 

Referring again to FIG. 12, and using the GP control 
record shown in FIG. 4 as an example, the system would 
determine (at 156) that the CurrentProtocol supports options 
and (at 158) will update CurrentProtocol to the master 
option descriptor of FIG. 6. The master option control record 
has one field shown in FIG. 6a, which is used to select the 
appropriate option protocol description structure to use. The 
lookup structure shown in FIG. 6ft allows option descrip- 
tions to be associated with option type values extracted from 
network frames. The system (at 160-166) will parse one 
option at a time in the current network frame until all options 
are parsed. 

Before each option is parsed, the number of bits parsed 
using the previous option protocol control record is sub- 
tracted from HeaderLen (at 162). The ParseFields control 
logic is alternately processed (at 164) with the master 
protocol option control record, and an appropriate option 
control record. The CurrentProtocol is updated (at 166) with 
the NextOption value returned by ParseFields, and the loop 
is re-entered (at 160). 

Using the exemplary frame, "Frame (2)," described above 
as an example with ParsePtr pointing at line 3, and Current- 
Protocol pointing at the GP master option description shown 
in FIG. 6, it may be seen how a NumBits value of zero 
prevents the master option description from contributing to 
the number of bits parsed (at 162), and how ParseFields and 



bits, and return NextProtocol as NULL. ParsePtr will point 35 Validate Value use the master option description field to 



at the start of line 3 in frame (2), and ParseLen will be 
updated to 272 bits. 

Referring now to FIG. 12, if a CurrentProtocol such as GP 
shown in FIGS. 5-5e supports optional fields, which is 
indicated by the Options field of the control record, then any 
options in the network frame are sequentially parsed (at 
160-166) using the ParseFields control logic (at 164) until 
ProtoParseLen, the number of bits parsed in the protocol 
header is equal to HeaderLen, the protocol header size 
determined during parsing with the original protocol 
description (at 152). 

Using the exemplary frame, "Frame (2)," described above 
as an example, after the GP fields are parsed (at 152), 
HeaderLen will be updated to 224 bits, while ProtoParseLen 
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select an appropriate GP option description structure from 
the lookup structure of FIG. 6b. For frame (2), the first 
option byte at line 3 contains value 1, which causes the GP 
NoOp option description structure shown in FIG. 8 to be 
selected (at 166). The NoOp NumBits value of 8 is added to 
ProtoParseLen (at 162), and the single field defined in FIG. 
8a is parsed at 164. In a preferred form, each option 
description structure must have a field with an associated 
lookup structure that is always processed and refers back to 
the master option description structure. 

Thus, for "frame (2)" the option processing control loop 
(at 160 through 166) is alternately applied with the descrip- 
tion structures of FIG. 6 and FIGS. 8, 9, and 7. The GP End 
Of List Option does not refer back to the master option 



will be updated to 160 bits, which indicates the presence of so description because it indicates an end to option processing. 



(224-160) bits of optional fields (at 160). 

Every protocol description with optional fields will have 
a master protocol option description, and one option proto- 
col description for each supported option. Using the GP 
protocol control record shown in FIG. 5 as an example of 55 
how optional fields might be described, the Options field 
will refer to a master option control record similar to FIG. 
6. The master option control record will contain one field 
(see FIG. 6a) that does not contribute to the number of bits 
parsed (BitLength zero) with an associated lookup structure 60 
(see FIG. 6b) for each possible option. Using FIG. 6b as an 
example, each defined option refers to an appropriate pro- 
tocol option description. The first field of each option 
description has an associated lookup structure (see FIGS. 7b, 
8ft, and 9ft) that refers back to the master option control 65 
record. FIG. 9a shows how optional fields with variable 
length may be handled by computing the frame length. 



Any remaining option bits are assumed to be pad and are 
disregarded so that the check for more options (at 160 in 
FIG. 12) will fail and return to frame protocol parsing (at 
108 in FIG. 11). 

Once all options have been parsed in frame (2) or the 
system (at 160) determines that the current frame has no 
optional fields as in frame (1), the system control logic (at 
168 or 170) will return to the main parsing loop (at 108 in 
FIG. 11). 

While the invention of this application is susceptible to 
various modifications and alternative forms, specific 
examples thereof have been shown in the drawings and are 
herein described in detail. It should be understood, however, 
that the invention is not to be limited to the particular forms 
or methods disclosed, but to the contrary, the invention is to 
cover all modifications, equivalents, and alternatives falling 
within the spirit and scope of the appended claims. 
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Whit is claimed is: 

1. A network filtering system comprising: 
means for storing in a first memory a plurality of pro- 
grammably configurable protocol descriptions, said 
plurality of programmably configurable protocol 5 
descriptions defining one or more filter criteria; 
means for storing in a second memory a program for 
controlling a data filtering function to be executed by a 
processing unit, said program including instructions for 
causing said processing unit to selectively retrieve at 10 
least one of said plurality of programmably config- 
urable protocol descriptions from said first memory and 



10 Bl 

24 

to vary the execution of said data filtering function 
based upon said at least one retrieved protocol descrip- 
tion; 

means for delivering to said processing unit said program 
for controlling said data filtering function; 

means for enabling said processing unit to execute said 
data filtering function; and 

means for delivering to said processing unit said data 
transmitted over a data communications network. 

* * * * * 
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[57] ABSTRACT 

Low-level network services are provided by network- 
service-provider plugins. These plugins are controlled by an 
extensible service provider that is layered above the TCP or 
other protocol layer but below the Winsock-2 library and 
API. Policy servers determine priority of network traffic 
through control points on a network. Examining packets 
passing through these control points provides limited data 
such as the source and destination IP address and TCP ports. 
Many applications on a client machine may use the same IP 
address and TCP ports, so packet examination is ineffective 
for prioritizing data from different applications on one client 
machine. Often some applications such as videoconferenc- 
ing or data-entry for corporate sales are more important than 
other applications such as web browsing. A application - 
classifier plugtn to the extensible service provider intercepts 
network traffic at above the client's TCP/IP stack and 
associates applications and users with network packets. 
These associations and statistics such as maximum, average, 
and instantaneous data rates and start and stop time arc 
consolidated into tables. The policy server can query these 
tables to find which application is generating network traffic 
and prioritize the traffic based on the high-level application. 
Bandwidth-hogging applications such as browsers can be 
identified from the statistics and given lower priority. 
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Application Open/Close Event 



Index 


C Type (VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


long (Long) 


Time 


The time of the event. This is 
the C time t value 
representing the number of 
seconds since 1/1/70 


2 


long (Long) 


ProcessID 


The process ID of the 
application 


3 


BSTR (String) 


Application 
Name 


The name of the application 


4 


BSTR (String) 


User Name 


The name of the currently 
logged in user. 


Figure ' 

Socket Open/4 


7A 

Close Event 


Index 


C Type (VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


long (Long) 


Time 


The time of the event. This is 
the C time t value 
representing the number of 
seconds since 1/1/70 


2 


long (Long) 


ProcessID 


The process ID of the 
application 


3 


long (Long) 


Socket 


The socket ID 


4 


long (Long) 


Flow ID 


The flow ID of the flow 
associated with this socket 


5 


long (Long) 


Network 
Protocol 


The network protocol (IP JPX) 
associated with this socket. 


6 


long (Long) 


Transport 
Protocol 


The transport protocol used by 
the socket. These values may 
be specific to particular 
network protocols. 



Figure 7B 
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Socket Bind/Connect/Accept Event 



Index 


C Type (VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


lone (Lone) 


Time 


The time of the event. This is 
the C time_t value 
representing the number of 
seconds since 1/1/70 


2 


long (Long) 


ProcessID 


The process ID of the 
application 


3 


long (Long) 


Socket 


The socket ID 


4 


long (Long) 


Flow ID 


The flow ID of the flow 
associated with this socket 


5 


long (Long) 


Local 
Address 


The IP address and port 
information 


6 


long (Long) 


Local Port 


7 


long (Long) 


Remote 
Address 


The IP address and port 
information 


8 


long (Long) 


Remote 
Port 



Figure 7C 



Flow Table 



Index 


C Type (VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


long (Long) 


Number of 
Flows 


The number of flows in the 
table 


2 


SAFEARRAY 
of VARIANT 


Flows 


This is an array of flows, 

where each flow is a 
Variant as described in the 
Figure 9A. 



Figure 9B 
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Socket Data In/Out Event 
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long (Long) 
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Version 


1 
1 


long (Long) 


i ime 
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seconds since 1/1/70 


2 


long (Long) 


ProcessID 


The process ID of the 
application 


3 


long (Long) 


Socket 


The socket ID 


4 


long (Long) 


Flow ID 


The flow ID of the flow 
associated with this socket 


5 


long (Long) 


Local 
Address 


The IP address and port 
information 


6 


long (Long) 


Local Port 




7 


long (Long) 


Remote 
Address 


The IP address and port 
information 


8 


long (Long) 


Remote 
Port 




9 


long (Long) 


Bytes 


The number of bytes sent or 
received 



Figure 7D 
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Flow Start/Stop Event 



Index 


C Type (VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


long (Long) 


Time 


The time of the event. This is 
the C timet value 
representing the number of 
seconds since 1/1/70 


2 


long (Long) 


ProcessID 


The process ID of the 
application 


3 


long (Long) 


Flow ID 


The flow ID of the flow 
associated with this socket 


4 


BSTR (String) 


Application 
Name 


The name of the application 


5 


BSTR (String) 


User Name 


The name of the currently 
logged in user. 


6 


long (Long) 


Network 
Protocol 


The network protocol (IPJPX) 
associated with this socket. 


7 


long (Long) 


Transport 
Protocol 


The transport protocol used by 
the socket. These values may 
be specific to particular 
network protocols. 


8 


long (Long) 


Local 
Address 


The IP address and port 
information 


9 


long (Long) 


Local Port 


10 


long (Long) 


Remote 
Address 


The IP address and port 
information 


11 


long (Long) 


Remote 
Port 



Figure 7E 



04/30/2003, EAST Version: 1.03.0002 



U.S. Patent 



Oct. 31, 2000 



Sheet 10 of 14 6,141,686 



CURRENT 



HISTORICAL 




APP 






PROCESS 




91 




FLOW 




93 


95 





FIG. 8 



04/30/2003, EAST Version: 1.03.0002 



U.S. Patent 



Oct. 31, 2000 Sheet 11 of 14 



6,141,686 



Flow Information 



Index 


CType 
(VB) 


Value 


Description 


0 


long (Long) 


Version 


Version 


1 


long (Long) 


FlowID 


The flow to which the 
information relates. 


2 


long (Long) 


ProcessID 


The process ID of application 
generating this flow. 


3 


BSTR 
(String) 


Application 
Name 


The name of the application 
generating this flow 


4 


BSTR 
(String) 


User Name 


The name of the currently 
logged in user. 


5 


long (Long) 


Start time 


The time the flow began. 


6 


long (Long) 


Stop time 


The time flow ended. Zero 
for ongoing flow. 


7 


long (Long) 


Transport 
Protocol 


Transport protocol. 


8 


long (Long) 


Net Protocol 


Protocol 


9 


long (Long) 


Source Port 


These entries identify the IP 
address information for the 
flow. 


10 


long (Long) 


Source Address 


11 


long (Long) 


Destination 
Port 


12 


long (Long) 


Destination 
Address 


13 


long (Long) 


Total Sent 


Total bytes sent in this flow 


14 


long (Long) 


Total Received 


Total bytes received in flow 


15 


long (Long) 


Max Rate 


These are the rates for the life 
of the flow for bytes sent and 
received. 


16 


long (Long) 


Min Rate 


17 


long (Long) 


Average Rate 


18 


long (Long) 


Delta Sent 


Total Sent, Total Received and 
Average Rate, but reset for 
each query. Delta Rate is 
calculated over the time 
between the queries. 


19 


long (Long) 


Delta Received 


20 


long (Long) 


Delta Rate 



Figure 9A 
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CLIENT-SIDE APPLICATION-CLASSIFIER 

GATHERING NETWORK-TRAFFIC 
STATISTICS AND APPLICATION AND USER 
NAMES USING EXTENSIBLE-SERVICE 
PROVIDER PLUGIN FOR POLICY-BASED 
NETWORK CONTROL 

RELATED APPLICATION 

This application is a continuation-in-part of the 
co-pending application for "Ordering of Multiple Plugin 
Applications Using Extensible Layered Service Provider 
with Network Traffic Fllering", U.S. Ser. No. 09/042,306, 
filed Mar. 13, 1998, now pending. 

FIELD OF THE INVENTION 

This invention relates to software for computer networks, 
and more particularly to client plugins for identifying appli- 
cation traffic-signatures, signaling traffic priorities, and for 
generating network statistics for policy servers. 

BACKGROUND OF THE INVENTION 

Computer networks such as the Internet are driving 
increased acceptance of personal computers. Network com- 
munication began with text-only e-mail and file-transfer 
protocols (FTP), but with improved user interfaces and 
graphics, graphical browsing has become commonplace. 
Mission-critical business transactions, corporate database 
queries, and even video conferencing and voice telephone 
calls all use the Internet. 

Not surprisingly, the Internet and local networks are 
becoming crowded. Simply increasing bandwidth is expen- 
sive and often only shifts bottlenecks to another part of the 
network. While users may not notice delayed e-mail, Inter- 
net browsing can become painfully slow during times of 35 
network congestion. Video conferencing and telephony suf- 
fer poor quality and even gaps of lost speech when the 
network is slow. 

FIG. 1 illustrates differing priorities of various kinds of 
network traffic. Two-way video and audio communications 
such as video conferencing and Internet telephony must 
have their packets delivered over the network in real time, 
or parts of the conversation are lost. Thus these services 
must have the highest priority in most networks. Business- 
critical applications such as financial transactions and 
accesses of corporate databases have moderately high pri- 
ority. Browser traffic to the wo rid -wide -web has a lower 
priority since much of this traffic is for information gathering 
and personal uses. However, browser traffic should not be so 
slow as to irritate the users. Lowest in priority are file 
transfers and e-mail, since these are usually not needed 
immediately. 

Server traffic tends to have a higher priority than client 
traffic, since business-critical applications reside on corpo- 
rate servers. Clients are usually individual desktop PC's. 
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Can't Determine Priority of IP Packets — FIG. 2 

I deally Ta~network de vice'such'as" a" rpuje^would read a 
packet's header and determine the priority of that packet 
from fields in the header. Unfortunately, determining the 
priority of packets passing through a network point is 
problematic. Simple filtering software can be used to iden- 
tify packets using certain network protocols such as TCP, or 
certain Internet Protocol (IP) addresses. 

FIG. 2 shows an Internet packet. Port fields 23, 24 identify 
which ports were assigned by the network software for 
communication with a higher-level application requesting a 
communications session. Destination port field 23 specifies 
the port on the destination machine, while source port field 
24 specifies the port on the source machine. Protocol 26 is 
a field identifying the network protocol used, such as TCP or 
UDP. Destination address field 28 contains the IP address 
that the packet is being sent to, while source address field 29 
contains the IP address of the sender of the packet. The 
contents or data of the packet, perhaps with additional 
higher-level headers, is contained in data field 22. 

While some applications may use certain ports, many 
applications use standard ports, such as port 80 for web 
browsers. Sometimes these ports are dynamically assigned 
to applications, so that different ports are used by the same 
application at different limes. Simply reading port fields 23, 
24 does not uniquely identify applications, so it is difficult 
to determine priority based on port fields 23, 24. Most 
applications use the TCP protocol, so protocol field 26 
likewise does not uniquely identify users or their applica- 
tions. 

IP address fields 28, 29 often uniquely identify a user or 
a server machine, and IP-address filtering has been used to 
restrict access by children to adult -only web sites. IP -address 
filtering has been less successful for blocking unwanted 
"junk" or "Spam" e-mail, since the IP-address fields are 
often altered to hide the originating IP address. Larger web 
sites may use many IP addresses that may dynamically 
change as the web site is updated. Even client machines can 
have dynamically-assigned IP addresses rather than a static 
IP address. In some organizations, many users share an IP 
address. Thus determining packet priority using IP addresses 
is not effective. 

Ideally, the names of the high-level application on the 
client and on the server machines should be collected. The 
high-level application names could then be uses for priori- 
tizing IP packets from these applications, rather than use IP 
addresses and TCP ports. 

Policy-Controlled Network — FIG. 3 



Quality-Of-Service Network Policy 

Attempts have been made to improve transmission speed 
of higher-priority traffic. Bandwidth-shaping or traffic- 
shaping delays low-priority traffic so that higher-priority 
packets can pass through with less delay. Quality-of-Service 
(QOS) is thus improved. Bandwidth can be reserved for the 
highest-priority applications such as video conferencing. 
See for example, U.S. Pat. Nos. 5,644,715 and 5,694,548, by 
Baugher et at., assigned to IBM; also U.S. Pat. No. 5,673, 
322 by Pepc et al., and U.S. Pat. No. 5,136,581 by^ 
Muehrchke, assigned to Bell Labs. 



FIG. 3 is a diagram of a network th at controls traffic using 
policy rules. aient-PGs40rl2'Send-lPpa^kete fry er locals 
c^etw ork^ l5 - to- ^ Edge 
55 ^^ce*T!ins*a^ 

^ - network -device- that-con nects -local :network-15t to -Internet 
t.20.Traditionally, routers such as edge device 14 have simply 
passed all packets through roughly in the order received, 
without regard to priority. 
60 Edg e device 14 is able to block or delay packets to and 
from Internet 20 so that higher-priority packets experience 
less delay than lower-priority packets. Edge device 14 may 
examine packets and apply policy rules to determine which 
packets to accelerate and which to delay. 
65 Policy server 18 sends the policy rules to edge dcviceT4: 
Bandwidth-information is sent back from edge~deviccT4 to 
policy server 18. This bandwidth information might indicate 
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the current bandwidth available to Internet 20 or local to the network media using physical layers such as a 

network 15, or other traffic or load statistics such as the kinds media-access controller (MAC). 

of packets appearing. The bandwidth information may be While direct communication from Winsock-2 library 34 
used by policy server 18 to re-prioritize packets passing to TCP layer 40 can occur, Winsock-2 provides a service- 
through edge device 14 by adjusting the policy rules sent to 5 prov ider interface (SPf) to third-party software modules 
edge device 14. For example, when edge device 14 detects known as layered providers or layered service providers, 
video conferencing packets passing through, policy server Instead of having many layered providers all communicating 
18 can reduce the bandwidth allocated to other kinds of with TCP layer 40, a single extensible service provider 50 is 
packets to reserve additional network bandwidth for video- installed. Extensible service provider 50 intercepts all net- 
conferencing packets. 10 wor k traffic at a lower level than the applications. Extensible 

Often higher-priority packets are generated by corporate service provider 50 fits between Winsock-2 library 34 and 

server 16 than client PCs 10, 12. Policy server 18 can set a TCP layer 40, operating on data sent from Winsock-2 library 

higher-priority policy for corporate server 16 when certain 34 to TCP layer 40 for transmission. Extensible service 

kinds of packets appear in the bandwidth information from provider 50 is "extensible" since it allows for the expansion 

edge device 14. 15 0 f network services. 

While such a policy-controlled network is effective, Extensible service provider 50 manages or controls the 

newer technologies make determining the priority of packets execution of additional network services provided by plu- 

more difficult. Low-priority web browsing from client 10 gins 52. Plugins 52 are reduced in size and complexity 

can be identified by the IP address for client 10 and port 80 compared with layered service providers because overhead 

used by the browser. However, newer software installed on 20 functions and filtering is performed for all plugins by 

client PC 12 dynamically assigns ports to applications. IP extensible service provider 50. 

addresses may also be changed using Dynamic Host Con- plugins 52 provide various extra network services such as 

figuration Protocol (DHCP). The application may appear as encryp tion, compression, security, proxies, or re-routing, 

port 50 one day, but port 22 on another day. The IP address network services are transparent to high level appli- 

assigned to client PC 12 may also be dynamically assigned 25 cations 32 and can 5e activated for all appucat jons using the 

or even shared by other client PCs. network. Extensible service provider supplies a framework 

Identifying web browser traffic from client PC 12 is thus for managing and ordering a wide variety of plugin services, 
quite difficult. Client PC 12 could be downloading huge Policy are desirable for prio ritizing and regulating 
graphics images from the Hubbell Space Telescope for network traffic. Policy servers can better prioritize IP pack- 
personal use, swamping the capacity of the network, while ^ wheQ ^ originating app i ication ^d user are known . 
client 10 waits to read text-based information from an Although IP packets do not identify the high-level applica- 
importanl customer over Internet 20 Network chaos erupts Uon or user that sent the ^ this iaformatioD ^ to 
when even a few users hog bandwidth for low-pnonty tasks. po]icy u is desircd to colkct informafion such as thc 

Security software may encrypt packets. Encryption may 35 originating application and user from client and server 

include the source IP address and port, preventing other machines that can be used by the policy server in making 

devices and servers from reading the source address of priority decisions. 

packets. However, information must be collected from the client 

Extensible Service Provider Accepts Network- and seiwr machines in a manner that is transparent to 

Service Plugins FIG 4 40 high-level applications. It is desired to install plugins on 

client and server machines that can be queried by the policy 
The parent application, U.S. Ser. No. 09/042,306, hereby server , A specialized plugin for the extensible service pro- 
incorporated by reference, discloses in detail an extensible v i der ^ desired that monitors and collects information on 
service provider that manages and orders network-service netW ork traffic from a client or server. This information 
plugins. FIG. 4 is a diagram of a network architecture using 45 includes the originating and destination high-level 
an extensible service provider that manages and orders applications, data rates, and users. It is desired to prioritize 
network-service plugins. The architecture is based on network traffic based on high-level applications and users 
Winsock-2, the second-generation network architecture for ralher than low-level IP addresses and TCP ports. 
Microsoft J s Windows operating systems. Winsock-2 pro- 
vides connections or "sockets" for high-level applications to 50 SUMMARY OF THE INVENTION 
connect to a network. A socket is the identifier for a given 

connection, or for a connectionless data-gram flow. A client-side application-classifier has an upper interface 

High-level applications 32 send and receive information t0 » higher-level network-socket library. The higher-level 

to a network by making calls to Winsock-2 library 34. ^^k-socket library proves high-level network func- 

Winsock-1 calls from high-level applications arc also routed 55 ,0nS 10 ^ a PP hcat ' ons b * generating a socket 
. ■ , • -I.,, <\,..u- „ tu B 11 v 4- for connecting to a remote machine on a network. A lower 

through in a similar lashion. Incse calls use an applications- - . fe , . , „ 

programming interface (API) that defines the function calls interface lS to 3 network-transport layer that formats data for 

and their syntax. Winsock-2 library 34 is a dynamic-link ^mission ° ver the network. An interceptor is coupled 

library (DLL) of these function calls and other network- between ^ Uppef and l0W6r mt " h ™- 11 inlcree P to net * 

support routines. 60 WOlk eVeDtS ' 

Earlier versions of Winsock communicated directly with examiner is coupled to the interceptor. It examines the 

the lower TCP layer 40, which provides a Transmission D . etwork cvent intercepted and cotlects statistical informa- 

Control Protocol for establishing sessions with remote hosts u on about the network event. The statistical information 

over a network. TCP layer 40 sends data to IP layer 42, includes: 

which splits the data into Internet-Protocol IP packels and 65 an application name of one of the high-level user appli- 

adds header information such as the source and destination cations that caused the network event; 

IP address. IP layer 42 sends and receives these IP packets a timestarap for the network event; 
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a byte count when the network event is a transfer of data 
over the network; 

Internet addresses and ports when the network event is a 
connection or a data transfer; and 

a process identifier of a running instance of the high-level 
user application. 

Aconsolidator is coupled to the examiner. It consolidates 
the statistical information into application-classifier tables. 
The application-classifier tables include current tables for 
currently- running instances of applications, and historical 
tables that include closed applications. A reporter is coupled 
to the consolidator. It sends the statistical information from 
the application-classifier tables to a remote policy server on 
the network. The statistical information includes the appli- 
cation name. Thus the statistical information for network 
events is collected by the client-side application-classifier. 

In further aspects of the invention the interceptor is an 
extensible service provider and the examiner is an 
application-classifier phigin to the extensible service pro- 
vider. The extensible service provider controls other plugins 
providing low- level network services. 

In still further aspects the examiner generates an event 
object containing the statistical information. The event 
object is sent to the consolidator and written into the 
application-classifier tables. The network event is: 

an application startup event when a high-level application 
is initialized; 

an application cleanup event when the high-level appli- 
cation is terminated; 

a socket open event when a new socket is opened; 

a socket close event when a socket is closed; 

a connect event when a connection is made from a client 
to a remote server; 

an accept event when a connection is accepted from a 
remote client; 

a send-complete event when a flow of data has been sent 
from the client to the remote server; and 

a receive-complete evenl when a flow of data has been 
sent from the remote server to the client. 

In further aspects the statistical information for all net- 
work events includes a process identifier. The application- 
classifier tables are indexed by the process identifier. The 
application-classifier tables store for each flow of each 
high-level application: 

the process identifier; 

the timestamp; 

the application name; 

the byte count when the network event is a transfer of data 

over the network; and 
Internet addresses and ports when the network event is a 

connection or a data transfer; 
and wherein an application-classifier table for a high-level 

application contains: 

maximum, average, and most-recent data-transfer rales 
for flows generated by the high-level application. 
In other aspects the network- transport layer is a TCP/IP 
data communications stack coupled to a first network 
through a first media-access control (MAC) adapter and 
coupled to a second network through a second MAC adapter. 
The client-side application-classifier also has a network 
enhancer that is coupled between the network-transport 
layer and the first and second media-access controllers. It 
intercepts network packets and extracts routing information 
including source and destination network addresses. 
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A route table is coupled to the network enhancer to store 
the routing information for the network packets. The exam- 
iner is coupled to the route table to determine a source 
address of either the first MAC adapter or of the second 
MAC adapter or other MAC adapters when the source 
address is not available from the upper interface. Thus 
source addresses for clients with two network connections is 
obtained by the network enhancer below the TCP/IP stack. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates differing priorities of various kinds of 
network traffic. 
FIG. 2 shows an Internet packet. 

FIG. 3 is a diagram of a network that controls traffic using 
policy rules. 

FIG. 4 is a diagram of a network architecture using an 
extensible service provider that manages and orders 
network-service plugins. 

FIG. 5 is a diagram of an application-classifier that plugs 
into an extensible service provider for network services. 

FIG. 6 is a table of events thai trigger the application- 
classifier plugin to send data objects to the controller for 
classification. 

FIGS. 7A-7E show definitions for objects that transfer 
data about network events from the application-classifier 
plugin to the controller for classification and storage. 

FIG. 8 shows the current and historical tables of network 
events maintained by the application-classifier consolidator. 

FIGS. 9A, 9B are diagrams of the format of an entry in the 
consolidator* s tables. 

FIG. 10 illustrates dual-level application-classifier plu- 
gins when multiple network addresses are used by a client. 

FIG. 11 shows how the application-classifier plugin is 
useful for providing information for policy control applica- 
tions in a policy server. 

FIG. 12 is a diagram of a network using policy rules 
determined by queries of application-classifier plugins 
installed on clients. 

DETAILED DESCRIPTION 

The present invention relates to an improvement in net- 
work policy servers and their clients. The following descrip- 
tion is presented to enable one of ordinary skill in the art to 
make and use the invention as provided in the context of a 
particular application and its requirements. Various modifi- 
cations to the preferred embodiment will be apparent to 
those with skill in the art, and the general principles defined 
herein may be applied to other embodiments. Therefore, the 
present invention is not intended to be limited to the par- 
ticular embodiments shown and described, but is to be 
accorded the widest scope consistent with the principles and 
novel features herein disclosed. 

High-Level Better Than Low-Level for 
Prioritization 

The inventors have realized that policy servers typically 
prioritize network traffic based on low-level IP addresses 
and TCP porls. Low-level prioritization is undesirable 
because IP addresses and TCP ports are often shared by 
many applications and users. All applications and users 
sharing IP addresses and ports would be given the same 
priority. Even when IP addresses are statically assigned to 
one machine, all applications on that machine may need to 
be given the same priority, even though some applications 
are inherently more important than others. 
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Ideally, a user is given high priority when using corporate 
applications such as client databases and sales forms, but 
lower priority when using personal, non-business applica- 
tions such as web browsing or graphics downloading. This 
requires that the names of the high-level applications and 
users be used for prioritizing network traffic, not just the IP 
addresses and TCP ports. 

The names of the high-level application and its users on 
the client and on the server machines can be collected using 
the invention. The high-level application names are then 
used by a policy server to prioritize IP packets from these 
applications, rather than only use IP addresses and TCP 
ports. The high-level application and user names are then 
associated with a traffic signature. The traffic signature is a 
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information such as the source and destination IP address. IP 
layer 42 sends and receives these IP packets to the network 
media using physical layers such as a MAC adapter. Mul- 
tiple high-level applications 32 can spawn multiple pro- 
cesses that use multiple stacks such as TCP/IP and other 
protocols (not shown). 

Instead of having many layered providers communicating 
with each other and TCP layer 40, a single extensible service 
provider 50 is installed, as described in detail in the parent 
application. Extensible service provider 50 intercepts all 
network traffic at a lower level than the applications. Exten- 
sible service provider 50 fits between Winsock-2 library 34 
and TCP layer 40, operating on data sent from Winsock-2 
library 34 to TCP layer 40 for transmission. Extensible 



unique representation of the user's application network 1 5 service provider 50 is "extensible" since it allows for the 



traffic which can include the IP address, TCP port, and some 
of the data in the packets. Packets matching the traffic 
signature can then be identified at various points in a 
network and acted upon. Thus network traffic is prioritized 
by user and application, rather than by machine. 

Since a policy server cannot consistently identify a high- 
level application by examining the IP packets passed 
through the network, the invention identifies network traffic 
by application and user. A software module on client or 
server machines collects information on network traffic from 
each client or server. A plugin for the extensible service 
provider on a client or server machine collect statistics on 
network traffic that can be read by a policy server. The 
collected statistics are arranged by user and high-level 
application and include data rates and time stamps. 

Current Invention is a Plugin Module for ESP of 
Parent Application 

The parent application, U.S. Ser. No. 09/042,306, hereby 
incorporated by reference, discloses in detail an extensible 
service provider (ESP) that manages and orders network- 
service plugins. The current invention includes a plugin 
module for the extensible service provider described in the 
parent application. This plugin module is used to collect 
network-traffic statistics and identify traffic signatures for 
applications. Since the traffic signatures collected include 
the name of the high-level application, the plugin is known 
as an application-classifier engine (ACE) plugin. 
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expansion of network services. 

Extensible service provider 50 manages or controls the 
execution of additional network services provided by plu- 
gins. Plugins are reduced in size and complexity compared 
with layered service providers because overhead functions 
and filtering is performed for all plugins by extensible 
service provider 50. 

Plugins provide various extra network services such as 
encryption, compression, security, proxies, or re-routing. 
These network services are transparent to high level appli- 
cations 32 and can be activated for all applications using the 
network. Extensible service provider supplies a framework 
for managing and ordering a wide variety of plugin services. 

One such plugin is application -classifier plugin 51. Other 
plugins (not shown) may also be installed and controlled by 
extensible service provider 50 and thus co-exist with 
application-classifier plugin 51. One or more filters can be 
performed by extensible service provider 50 to reduce the 
amount of traffic that activates application-classifier plugin 
51. In the preferred embodiment no filters are used so that 
all network traffic activates application-classifier plugin 51. 
Thus network statistics are collected on all traffic passing 
through extensible service provider 50 to and from TCP 
layer 40. 

Application -classifier plugin 51 is a Windows DLL that is 
loaded by extensible service provider 50 on initialization. 
Extensible service provider 50 reads a list of plugins to load 
from the Windows registry and loads all the listed plugins, 



The application-classifier plugin resides on client and/or 45 including application-classifier plugin 51. When 



server machines and each collects network statistics for 
packets originating from or received by the machine. A 
policy server gathers information from the machines by 
polling the application-classifier plugin in each client and 
reading the collected statistics. Alternately, each client can 
periodically send the collected information to the policy 
server. The policy server can then make policy decisions and 
prioritize network traffic based on the information collected 
from the clients' application-classifier plugins. 

Application-Classifier Plugs Into Extensible Service 
Provider— FIG. 5 

FIG. 5 is a diagram of an application-classifier that plugs 
into an extensible service provider for network services. 
High-level applications 32 send and receive information to 
a network by making calls to Winsock-2 library 34. These 
calls use an applications-programming interface (API) that 
defines the function calls and their syntax. Winsock-2 library 
34 is a dynamic-link library (DLL) of these function calls 
and other network-support routines. 

TCP layer 40 sends data to IP layer 42, which splits the 
data into Internet-Protocol IP packets and adds header 



application-classifier plugin 51 is loaded, it attaches itself to 
one or more of the filters registered with extensible service 
provider 50. In the preferred embodiment, application- 
classifier plugin 51 attaches itself to a universal filter that 
50 activates application-classifier plugin 51 for all network 
traffic. 

When an event occurs, such as a command or call from 
Winsock-2 library 34 or from TCP layer 40, or completion 
of network I/O, extensible service provider 50 compares the 
55 properties of the event to each of its filters and generates an 
event activating all plugins attached to matching filters. 

Application-Classifier Components 

When an event activates application-classifier plugin 51, 
60 a data object containing details of the event is sent to 
controller 62. Controller 62 classifies the event and updates 
tables maintained by application-classifier-engine (ACE) 
consolidator 60. Consolidator 60 keeps tables of the most- 
recent events for each application and process, but also 
65 keeps historical tables of past events, even for applications 
thai have closed their connections and sockets. Statistical 
fields in the tables are also updated, such as the number of 
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bytes sent by an application or any of its processes, and 
timestamps when connections were opened and closed. 

A remote policy server can access the tables stored by 
consolidator 60 by connecting with DCOM server 64. 
DCOM server 64 contains proxy and stub objects that hide 
the details of network communication from higher- level 
application programs. DCOM server 64 uses Microsoft's 
Distributed-Component-Object Model (DCOM) of distrib- 
uted programming objects. Winsock-2 library 34 receives 
calls from DCOM server 64 that send and receive data 
packets over the network, passing down the protocol slack 
through TCP layer 40 and IP layer 41. When a remote policy 
server connects as a client to DCOM server 64, a request can 
be sent from the remote policy server, over the network to 
controller 62. The request can instruct controller 62 to fetch 
one or more of the tables stored by consolidator 60 and send 
them back over the network to the policy server. Controller 
62 and DCOM server 64 can be combined into a single 
controller module. 

Real-time information may also be collected by a remote 
policy server. The policy server can register with controller 
62 for certain kinds of events. For example, a policy server 
may need to know when a certain high-priority, high- 
bandwidth application such as videoconferencing opens a 
connection. The policy server can send the registration 
request through DCOM server 64 to controller 62. When- 
ever a connection for the high-priority videoconferencing 
application is opened and the event received by application- 
classifier plugin 51, controller 62, on receiving the event 
object from application-classifier plugin 51, sends the event 
object to DCOM server 64 to be immediately sent over the 
network to the policy server. The policy server can then 
reserve bandwidth for the videoconferencing application's 
packets before they arrive. 

Objects Generated by Application-Classifier Plugin 
for Events— FIG. 6 

FIG. 6 is a table of events that trigger the application- 
classifier plugin to send data objects to the ACE controller 
for classification. Events are generated by the Winsock-2 
library when an application starts or ends, when it opens or 
closes a socket, when the connection state of the socket 
changed, and when data is sent or received. 

Events can be grouped into three categories. Application 
events occur when a high-level networking application on 
the client machine opens or closes. Socket events are gen- 
erated when a socket is opened, closed, changes its connec- 
tion state, or the data is sent or received. A flow event occurs 
when a datastream begins or ends. 

FIG. 6 shows that the EventAppStart object is generated 
by the application-classifier plugin when an application 
startup event occurs. A startup event is signaled by the 
extensible service provider by activating the application- 
classifier plugin at the Startup entry point. The EventApp- 
Stop object is generated when an application cleanup event 
occurs, such as when the extensible service provider acti- 
vates the application-classifier plugin at the Cleanup entry 
point. The application starting up or cleaning up makes a 
Winsock-2 API call, which is passed down to the extensible 
service provider which generates the proper entry point into 
the application-classifier plugin. 

Either the AppStart or the AppStop object generated by 
the application-classifier plugin is sent to the ACE control- 
ler. The AppStart and AppStop objects use the EventAppInit 
data-object definition, shown in FIG. 7A. 

Several different kinds of socket events can occur. The 
SocketOpen, SocketClose, SocketBind, SocketAccept, and 



SocketConnect objects are generated by the application- 
classifier plugin when one of the closely-named Winsock 
API functions is called. For example, when an application 
opens a socket with a WSASocket API call, Winsock-2 
generates a WSPSocket SPI call to the extensible service 
provider, which activates the application-classifier plugin at 
the SocketOpen entry point. When the lower-level TCP layer 
determines that the connection with the remote machine has 
been made, the ConnectComplete event is generated. 

Different kinds of objects are generated for socket events. 
The EventSocketlnit data -object definition (FIG. 7B) is used 
to generate the SocketOpen and SocketClose objects sent to 
the ACE controller, while the EventSocketState data-object 
definition (FIG. 7C) is used to generate the SocketBind, 
SocketAccept, and SocketConnect objects when the socket 
slate is changed and the BindComplete, AcceptComplete, 
and ConnectComplete events occur. 

Completed data transfers signaled by the RecvComplete 
and SendComplete events generate the Socketln and Sock- 
etOut objects, which are based on the EventSocketDataXfer 
data-object definition (FIG. 7D). 

Flow events occur when a datastream completes. A flow 
is a connected TCP data stream or a sequence of uncon- 
nected (UDP) data-grams to and/or from a unique IP address 
and port. For TCP (connection oriented) steams, Connect- 
Complete signals the start of a flow in most cases. Some 
Winsock applications do not wait for completion of a 
connection: they simply initiate the connection and attempt 
to send or receive, assuming that data is transferred when the 
connection is made. In this special case, the triggering event 
for the flow is the combination of a ConnectComplete event 
and successful data transfer, signaled by RecvComplete and 
SendComplete events. 

For unconnected UDP data-grams, the first data success- 
fully sent or received from a unique IP address and TCP/ 
UDP port defines the start of a flow. This is indicated by the 
RecvComplete and SendComplete events that generate the 
Socketin and SocketOut objects. 

When the flow begins, either the ConnectComplete event 
for TCP or the RecvComplete and SendComplete events for 
UDP, the FlowStart object is generated, based on the Event- 
Flowlnit data-object definition (FIG. 7E). The end of the 
flow is signaled by the Socket Close event, which generates 
a FlowStop object also based on the EventFlowInit data- 
object definition 89. 

Data Objects— FIGS. 7A-7E 

FIGS. 7A-7E show definitions for objects that transfer 
data about network events from the application-classifier 
plugin to the ACE controller for classification and storage. 
The triggering events for these objects were shown in FIG. 
6. Each of the tables in FIGS. 7A-7E and 9A, 9B describe 
array data objects that are transferred. 

FIG. 7A shows the EventAppInit data-object definition. A 
version number is the first parameter in the definition. A 
timcstamp is stored for the time that the event activated the 
application-classifier plugin. The unique process ID for the 
Winsock process that originated the event is stored in the 
60 ProcessID field. One application can spawn several network 
processes, but each process is identified by a unique ID 
assigned by the Windows operating system. 

The name of the high-level application is retrieved using 
the Win32 API library call GetModuleFileName. Thus the 
65 objects based on EventAppInit data-object definition include 
the names of the application, user, and host, as well as a 
timcstamp and the unique process ID. 
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FIG. 7B shows the EvenlSocketlnit data-object definition. 
Aversion number, timestamp, and the unique process ID are 
stored. The socket handle and the network-layer (IP, IPX) 
and Iransport-layer (TCP or UDP) protocols are also stored. 

The application and user names are not contained in the 
socket objects since the unique process ID can be used to 
associate the information with the corresponding application 
and user. An event created by the process such as a StartUp 
event contained the application and user names. Thus the 
consolidator already has the association of the unique pro- 
cess ID to the application before any socket events occur. 

FIG. 7C shows the EventSocketState data-object defini- 
tion. A version number, object timestamp, and the unique 
process ID are stored. The socket parameter is the value of 
the socket handle assigned by the Winsock library. The local 
and remote addresses are also stored. These are the desti- 
nation and source IP addresses and TCP/UDP ports. For 
SocketBind objects, the remote address is not yet known and 
the remote address field is set to zero. 

The EventSocketDataXfer data-object definition is shown 
in FIG. 7D. Again, a version number, timestamp, and the 
unique process ID are stored. The socket address and the 
local and remote addresses are also stored. The number of 
bytes in the transfer is also stored in the Bytes parameter. 
The number of bytes transferred is a useful statistic, since 
the policy server can use it to determine the bandwidth used 
by the application. Bandwidth hogs can thus be identified. 

FIG. 7E highlights the EventFlowInit data-object defini- 
tion. Flows are sequences of data packets sent or received 
between two endpoints. The version number, timestamp, and 
the unique process ID are stored. A unique flow ID that was 
assigned by the ACE plugin is also stored, since each 
process can generate several flows. 

The transport-layer and network-layer protocols are 
stored in the flow object. The source and destination IP 
addresses and TCP/UDP ports are also stored in the object. 

Current and Historical Tables in Consolidator — 
FIG. 8 

FIG. 8 shows the current and historical tables of network 
events maintained by the application -classifier consolidator. 
Statistical data stored in the tables include overall byle 
counts of data sent or received, average and maximum bytes 
sent/received per second, and start and stop timestamps of 
processes and flows. 

Current tables 92, 94, 96 are snapshots of currently- 
running applications, processes, and flows. When a flow, 
process, or application closes, its table entry is deleted from 
the current tables. Thus a policy server reading current tables 
92, 94, 96 might not see statistics for applications or flows 
that recently closed. 

Historical tables 91, 93, 95 contain entries for both 
running and closed applications, processes, and flows. His- 
torical tables 91, 93, 95 can contain only a limited number 
of entries; once the limit is reached, the oldest entry of all the 
applications, processes, or flows is deleted to make room for 
a new entry. Flow historical table 95 is more likely to fill up 
before process historical table 93 or application historical 
table 91, since a single application can generate several 
processes, and each process can generate many flows. Of 
course, the sizes of the tables can be adjusted to allow more 
room for flow table 95 and process table 93 than for 
application table 91. 

Application tables 91, 92 each contain no more than one 
entry for each application. Network statistics arc consoli- 



dated into the single entry for all processes and flows for the 
application. Thus a policy server can read an entry for a 
specific application to find out how many bytes the appli- 
cation has sent or received, regardless of how many con- 
5 nections have been made for the application. This allows 
high-bandwidth applications to be quickly identified. If two 
or more instances of an application are running, their net- 
work statistics are combined into a single entry in applica- 
tion table 92. Thus if a user as multiple browser windows 
10 running, the total browser traffic can be found in application 
table 92. Likewise, when an application is closed and 
restarted, a running total statistic for all previous instances 
of the application is kept. Restarting the application thus 
does not reset the usage statistics. 
15 A finer granularity to network statistics is stored by 
process ID in process tables 93, 94. Each unique process ID 
contains one entry per table. When another instance of an 
application is started, a second process ID is assigned to it, 
and a second entry is created in process table 93. When an 
20 application is closed and later restarted, the restarted appli- 
cation has a different process ID than the application did 
before it was closed. Separate entries are stored in historical 
process table 93, although only the running processes have 
an entry in current process table 94. 
25 Flow tables 95, 96 provide the finest granularity of 
network statistics. Each unique flow has its own entry. 
Different flow ID's are assigned to each flow generated by 
an application. Their entries are placed into historical flow 
table 95. 

Storage space can be reduced when the consolidator 
stores only flow tables 95, 96. When the policy server or 
ACE controller reads an entry in the application or process 
tables, the entry can be generated on the fly by the consoli- 
dator. All flow-table entries for the requested process or 
application are read, and their entries merged. Byle counts 
are summed, and average and maximum transfer rates and 
start and stop times are calculated for the process or appli- 
cation. Since table queries are less frequent than updates, 
overall processing is reduced by storing just the finest- 
granularity tables and generating the coarser-table entries. 

Consolidator Table Entries— FIGS. 9 A, B 

FIGS. 9A, 9B are tables of the format of an entry in the 
45 consolidator's tables. Again, a version number, the unique 
process ID and the flow ID are stored. For application 
entries, the most-recent process ID and most-recent flow ID 
are stored. Process entries store the most-recent flow ID. The 
application and user names stored at the end of the entry 
50 allow the application and user names to be found. The start 
and stop times of applications, processes, or flows are stored 
in historical tables. For current tables, the application, 
process, or flow has riot yet terminated, so the stop time is 
set to zero. For historical tables, the stop time is the time the 
5S last process instance of the application or flow was termi- 
nated. 

The transport protocol (TCP, UDP, etc.) is stored along 
with the source and destination IP addresses and TCP ports. 
For application and process tables, these are the addresses 

60 and protocols for the most-recent flow. 

Statistical information, such as byte counts, is also stored. 
Separate fields store the total number of bytes sent and the 
total bytes received for the application, process, or flow. The 
maximum and the minimum number of bytes sent or 

65 received in any one-second period is stored in the MinRate 
and MaxRate fields. The average byte rate is stored as 
AvgRate. 
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A sample of the rate can be taken over a specified period. Plugins Useful for Policy Control — FIG. 11 

The number of bytes sent and received during the sample fjq u sno ws how the application -classifier plugin is 

period is stored in DeltaBytesSent and DeltaBytesRecvd. useful for providing information for policy control applica- 

The length of the sample period is stored as DeltaRate. In ti ons m a policy server. The application-classifier plugin can 

FIG. 9B, a flow table is shown. It contains an array of flows, 5 periodically send the collected statistics to a server by 

with each flow as shown in FIG. 9A. All the flows on a creating network calls to send packets containing the statis- 

machine can be counted using the flow table of FIG. 9B. [j cs The application-classifier plugin is transparent to 

UAri 1D . T m di ■ vir> in higher-level applications since it operates between the 

MAC-Uvel Route-Table PIugm-FIG. 10 Winsock-DLL called by the applications and the lower-level 

FIG. 10 illustrates dual-level application-classifier plu- 10 TCP/IP stack, 

gins when multiple network addresses are used by a client. Policy control is implemented by policy server 18, which 

Some client machines connect to more than one network. collects detailed statistics of network traffic from various 

For example, the client machine may have two Ethernet network nodes such as client 10. High-level applications 32 

LAN cards, or a Token-Ring and an Ethernet card, or a i n client 10 include www browsers, corporate database 

Ethernet card and a dial-up modem connection. Two IP 15 v i ewers an( j data-entry terminal apps, and workgroup apps 

addresses are assigned to the client machine. Packets from such as network-enabled word processors and spreadsheets 

TCP/IP layers 40, 42 may be assigned either IP source an d other editors. Winsock-2 library receives calls from 

address, depending on which network the data is sent out applications 32 for access to the network These calls are 

over. For unconnected UDP datagrams, Winsock is not passed down to extensible service provider 50, which filters 

notified by TCP/IP layers 40, 42 of which IP address is used. 20 lnese ca jjg anc j execu t e s one or more plugins. 

Thus application-classifier plugin 51 is not able to determine Application-classifier plugin 51 intercepts and analyzes 

the source IP address for this special case. lhc netW ork traffic from client 10. The analyzed or modified 

Network enhancer 68 is a low-level network driver data from application-classifier plugin 51 is sent back to 

installed below IP layer 42 but above media-access- extensible service provider 50 and sent down through TCP 

controller MAC drivers 70, 70'. MAC drivers 70, 70' are 25 layer 40 and IP layer 42 and finally out over the network, 

software drivers that transfer data to network adapter cards E acn event, such as opening or closing a socket, making 

on the client machine and control the cards. Two different or breaking a connection, or transferring data packets is 

network connections are made by MAC drivers 70, 70', each intercepted by application-classifier plugin 51. The event is 

using a different source IP address. analyzed and classified by application-classifier controller 

Network enhancer 68 is installed by the operating system 62, which updates tables in application-classifier consolida- 

as a low-level driver (a Network Device Interface Specifi- tor 60. Thus statistics on network traffic from client 10 are 

cation NDIS shim) that intercepts all outgoing and incoming stored in the tables of application-classifier consolidator 60. 

network traffic. A filter is used by network enhancer 68 to The Winsock-2 API is provided for use by the plugins. 

intercept only ARP Address Resolution Protocol data that is ^ This API is useful for allowing the plugins lo communicate 

sent prior to a datagram, since the ARP protocol specifies the with remote servers such as the policy server. For example, 

destination and source IP addresses. The filter activates application-classifier controller 62 can use Winsock calls to 

route-table plugin 66 when ARP traffic is detected. Route- send ("push") data over the network using TCP layer 40" 

table plugin 66 is a plugin module that receives the IP and IP layer 42". 

addresses from network enhancer 68. The destination and ^ Policy server 18 may observe some packets from client 

source IP addresses are captured by route-table plugin 66 io, but does not know what priority to assign to them. A 

and stored in a route table of source and destination IP po ii cy application 32 can make a call to Winsock-2 library 

addresses by route-table plugin 66. 34. that js xn[ through extensible service provider 50', TCP 

When an unconnected datagram is sent through extensible layer 40', and IP layer 42' to client 10 over the network. This 

service provider 50 to TCP/IP layers 40, 42, application- 45 call can be directed to DCOM server 64 in client 10, asking 

classifier plugin 51 queries route-table plugin 66 for the what kind of traffic was recently sent. DCOM server 64 

source IP address used by TCP/IP layers 40, 42. reads the tables in application-classifier consolidator 60 to 

Application-classifier plugin 51 then generates the event obtain the desired information. DCOM server 64 then 
object using the source IP address obtained from route-table responds to policy server 18 by sending the desired 
plugin 66, and sends the event object to controller 62 . 50 information, such as a log of packets sent, together with their 
Controller 62 classifies the event object and updates the applications 32 that generated the packets and other high- 
application, process, or flow tables in ACE consolidator 60. level information that may not be contained in the packets 
A remote policy server can read the table objects of con- sent. 

solidator 60 through DCOM server 64 as described earlier. Other information may be requested by policy server 18, 
Application-classifier plugin 51 queries route-table plugin 55 such as the number of bytes sent by any particular applica- 
66 by performing a user-mode to kernel call. Such kernel tion 32 on client 10, or the total number of packets sent in 
calls can hurt performance. However, such a call is required a time period. The highest burst rate of packets or the 
only once for each new flow, and only for clients connected average packet transmission rate can also be obtained, 
to two or more networks. An alternative is to store the route DCOM server 64 allows easier object-oriented program- 
table in the Windows registry. eo ming techniques to be used, hiding the details of network 
The inventors have recognized this unusual problem communication from higher-level programmers. Stub and 
caused by Winsock-2 not providing the source IP address for proxy objects arc used on local and remote machines to 
unconnected datagrams. The problem is only apparent when facilitate communication over the network. Extensible scr- 
two or more network adapters are connected to a system. vice provider 50' on policy server 18 is not required and can 
Dropping prices of network adapter cards and use of 65 be eliminated in some embodiments, 
modems may make dual-network systems more common in Thus policy server 18 is able to query clicnt 10 by using 
the future. application-classifier plugin 51, which analyzes and logs 
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network traffic from client 10. More sophisticated schemes collected using the invention. The high-level application 

could have policy server 18 deciding that the traffic from names then can be used for prioritizing IP packets from these 

client 10 is low-priority, and instructing application- applications, by associating the application name and its 

classifier plugin 51 or another traffic-blocking plugin (not associated flows with traffic signatures. Thus network traffic 

shown) to block traffic from a particular application 32 in 5 is prioritized by user and application, rather than by 

client 10. Thus network traffic can be blocked from the machine. A user may have high priority when using corpo- 

source rate applications such as client databases and sales forms, 

The policy enforcer (policy server) is able to identify the but lower P riorit y when usm S personal non-business appU- 

user and the high-level application of network packets by catl0DS such as web browsm g or S ra P hlcs downloading, 

polling the application-classifier on the client machine. The io Information can be collected from the client machines in 

IP address and TCP port are sent from the policy server to a manner that is transparent to high-level client applications, 

lookup the packet's user and application in the history tables Phigins installed on client machines can be queried by the 

kept by the application-classifier consolidator. policy server. A specialized application-classifier ACE plu- 

Plugins enable policy controls to be implemented in a 8"? for the ej£tensible service provider monitors and collects 

manner transparent to higher-level applications. Plugins " information on network traffic from z . chent This informa- 

provide a way for network software to more closely examine . the ™ginating destination high-level 

network traffic from any machine, and even exert control applications, data rates, and users. Network traffic is pnon- 

over that machine's traffic. Uzed based 0D high-level applications rather than low-level 

IP addresses and TCP ports. 

Policy Server Queries Clients — FIG. 12 20 The layered network architecture of the extensible service 

HG. 12 is a diagram of a network using policy rules P 1 ™?" allo J w ] s third-party service providers to be 

determined by queries of application-classifier plugins ^ sta ^ in addltlon }° the apphcaUon-classifier ACE plugin. 

installed on clients. Policy server 18 queries application- ^ e Winsock-2 architecture is expanded for network ser- 

classifier plugins installed on client PC's 10, 12, as V1CCS P r0Vldcd at a low level These network services can 

described for FIG. 5. The DCOM servers on client PCs 10, 25 transparently intercept network traffic^ The complexity of 

12 are used by policy server 18 to connect and read the ACE a y ercd Providers is reduced and redundant filtering by each 

tables stored by the consolidators. Thus policy server 18 is la / ercd P™" 1 " f eliminated by using the ex ensible ser- 

able to determine which high-level application and which vice P rovide /- An expandable system that manages, 

user is sending packets through edge devke 14 by perform- or S ams * s * and orders low-level network service providers is 

ing a lookup of the ACE tables on client PC's 10, 12 for the 30 attained. Plugins are executed in a funcuonally correct order 

flow table having the source and destination IP addresses when man * layered service provider plugins from 

and TCP ports of the packets seen at edge device 14. The dlffercilt vendors are stalled. 

application and user names are stored with the matching The* P lu S ins are simplified compared with Winsock-2 

entry in the flow table layered service providers, since overhead for communica- 

Policy server 18 can also find bandwidth -hogging appli- 35 J** th f Winsot *; 2 librarv and * c TCP arc 

cations by reading all historical application ACE tables on handlcd ^tensible service provider. Since there are 

client PC s 10, 12, and comparing the average and maxi- man ? Winsock-2 fuoc ions that are not used by most 

mum byte rate fields to acceptable thresholds. Applications P 1 ^ 05 ' » hc °^ crhead f ° r , these ^^used factions is 

with high transmission rates can be identified, and policy M rontamed in the extensible service provider reducing the 

server 18 can instruct edge device 14 to block or delay 40 the plugins. Complex I/O such as blocking, 

packets for flows originating from these applications. The J 011 ^^/ 1 ^^^ 3 ° f CVCntS ' ovcrla PP ed arc 

flows for an application can be read from the ACE tables. handled by the bbP. 

Client PCs 10, 12 send IP packets over local network 15 ALTERNATE EMBODIMENTS 

to corporate server 16 and Internet 20. Edge device 14 is a 45 Several other embodiments are contemplated by the 

router, switch, gateway, modem or other network device that inventors. For example, many software implementations 

connects local network 15 to Internet 20. Edge device 14 is us i ng manv different programming languages are possible, 

able to block or delay packets to and from Internet 20 so that The invention may be adapted for UNIX and other operating 

higher-priority packets experience less delay than lower- systems, as well as future versions of Windows. Indeed, 

priority packets. Edge device 14 may examine packets and 50 UNIX-DCOM servers arc now appearing, allowing a UNIX 

apply policy rules to determine which packets to accelerate po ii cy server to access the application-classifier tables resid- 

and which to delay. ing on a Windows machine. Rather than use distributed 

Policy server 18 can still send a policy query to corporate objects, the information can be sent using a management 

server 16, which may or may not have the application- protocol such as SNMP or via FTP. 

classifier plugin installed. Corporate server 16 can respond 55 Edge devices may also be installed at internal points in a 

that certain of its packets are high or low priority. Also, network, such as between sub-nets in a corporate Intranet, 

corporate server 16 may indicate if an IP address is high or Many edge devices can be employed in a single network, 

low priority. Indeed, the invention can be applied to traffic within a local 

Low-priority web browsing from client 10 can be iden- network or within an Intranet. One or more policy servers 

tified by finding the application name in the flow tables for 60 collect information from application-classifiers on clients or 

the IP address for client 10 and port 80 used by the browser. at intermediate points, and control these edge devices. 

Even dynamically assigns ports or IP addresses can be Routers, bandwidth control boxes, switches, firewalls, and 

associated with their sending applications. Virtual Private Networking (VPN) boxes, as well as Net- 

„ work Management systems can use need the information 

ADVANTAGES OF THE INVENTION fi5 that lhc app Ltion -classifier can provide. These intermedi- 

The names of the high-level application and its associated ate devices can be integrated with clients or servers using the 

user on the client and on the server machines can be invention. 
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Edge devices may not only limit traffic from certain 
applications identified by the application-classifier, but 
modify the traffic as well. Far example, some applications 
may transmit confidential or sensitive information. The edge 
devices can encrypt packets for flows from such applications 
identified by the application-classifier. The application- 
classifier plugin itself, or another installed plugin can be 
used to block network traffic from the client, rather than the 
edge device. The policy server can program the plugin on the 
client machine to block packets from certain low-priority 
applications, or block after a threshold number of bytes have 
been sent in a time period. Thus network traffic can be 
blocked at the source, the client PC. 

The invention can also be used for other classification 
purposes. Identifying application traffic enables security, 
access, routing, discard, and other tasks. Decisions can be 
made either remotely through a policy server or infrastruc- 
ture device (gateway, router, bandwidth control device, or 
switch) or locally on the host system itself. In a very simple 
case, the invention can be used locally to effectively include 
the policy server on the same system. This approach might 
enable a user of a cable modem or DSL service to request a 
higher level of service from a network (and promise to pay 
accordingly). Usually, this selection of service would be 
done per application, e.g. if the user wanted to receive real 25 
time video, invoke IP telephony, or just get a file transferred 
more quickly. 

Security applications can examine outgoing packets and 
encrypt packets only from certain applications, such as 
financial applications. Other applications from the same IP 
address, such as e-mail, can be skipped and sent out without 
encryption. 

Other network-based, distributed-object programming 
standards besides DCOM can be substituted, such as 
CORBAor COPS. Future improvements to Winsock-2 can 
also be used with the invention. Earlier versions of Winsock 
communicated with both TCP and UDP, and UDP can be 
substituted for the TCP layer with the invention. 

The invention has been described as filtering packets. 
However, data may not yet be divided into the final packets 
transmitted over the network media when intercepted by the 
extensible service provider. The data sent from the 
Winsock-2 library functions down to the extensible service 
provider and the TCP layer may be further divided by the 
TCP and IP layers into smaller packets for transmission. 
Thus the term "packets" when used for the extensible 
service provider do not strictly refer to the final transmitted 
packets, but to the data and header information that will 
eventually form one or more packets. 

The invention can also work with other protocols such as 
SNA, IPX, X.25, etc. It is not restricted to IP (TCP, UDP, 
etc). The invention is extensible to perform more granular 
classification of traffic. For example, print and file transfer 
traffic may be mixed with interactive traffic sent from a 
single application. The invention can break these out into 
unique flows, identifying the traffic signatures for each 
, subflow^ Two examples of this are tn3270 which combines 
terminal traffic, print traffic and file transfer traffic in a single 
telnet session, and a SAP/R3 application which has a variety 
of financial transaction types (including printing). The 
invention can provide extensions to identify the traffic 
signatures of individual transactions. 

The foregoing description of the embodiments of the 
invention has been presented for the purposes of illustration 
and description. 1 1 is not intended to be exhaustive or to limit 
the invention to the precise form disclosed. Many modifi- 
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cations and variations are possible in light of the above 
teaching. It is intended that the scope of the invention be 
limited not by this detailed description, but rather by the 
claims appended hereto. 
We claim: 

1. A client-side application-classifier comprising: 

an upper interface to a higher-level network-socket 
library, the higher-level network-socket library for pro- 
viding high-level network functions to high-level user 
applications by generating a socket for connecting to a 
remote machine on a network; 

a lower interface to a network-transport layer, the 
network-transport layer for formatting data for trans- 
mission over the network; 

an interceptor, coupled between the upper and lower 
interfaces, for intercepting network events; 

an examiner, coupled to the interceptor, for examining the 
network event intercepted and collecting statistical 
information about the network event, the statistical 
information including: 

an application name of one of the high-level user 

applications that caused the network event; 
a timestamp for the network event; 
a byte count when the network event is a transfer of 

data over the network; 
Internet addresses and ports when the network event is 

a connection or a data transfer; and 
a process identifier of a running instance of the high- 
level user application; 
a consolidator, coupled to the examiner, for consolidating 
the statistical information into application-classifier 
tables, the application -classifier tables including cur- 
rent tables for currently-running instances of 
applications, and historical tables that include closed 
applications; and 
a reporter, coupled to the consolidator, for sending the 
statistical information from the application-classifier 
tables to a remote policy server on the network, the 
statistical information including the application name, 
whereby the statistical information for network events is 
collected by the client-side application-classifier. 

2. The client -side application-classifier of claim 1 wherein 
the interceptor is an extensible service provider and wherein 
the examiner is an application-classifier plugin to the exten- 
sible service provider, the extensible service provider for 
controlling other plugins providing low-level network ser- 
vices. 

3. The client -side application-classifier of claim 1 wherein 
the examiner includes means for generating an event object 
containing the statistical information, the event object sent 
to the consolidator and written into the application-classifier 
tables. 

4. The client -side application-classifier of claim 1 wherein 
the network event is selected from the group consisting of: 

an application startup event when a high-level application 
is initialized; 

an application cleanup event when the high-level appli- 
cation is terminated; 

a socket open event when a new socket is opened; 

a socket close event when a socket is closed; 

a connect event when a connection is made from a client 
to a remote server; 

an accept event when a connection is accepted from a 
remote client; 

a send-complete event when a flow of data has been sent 
from the client to the remote server; and 
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a receive-complete event when a flow of data has been 
sent from the remote server to the client. 

5. The client -side application-classifier of claim 4 wherein 
the statistical information for all network events includes a 
process identifier, wherein the application-classifier tables 5 
are indexed by the process identifier. 

6. The client -side application-classifier of claim 5 wherein 
the application-classifier tables store for each flow of each 
high-level application: 

the process identifier; 
the timestamp; 
the application name; 

the byte count when the network event is a transfer of data 

over the network; and 
Internet addresses and ports when the network event is a 15 

connection or a data transfer; 
and wherein an application-classifier table for a high-level 

application contains: 

maximum, average, and most-recent data-transfer rates 
for flows generated by the high-level application. 20 

7. The client-side application-classifier of claim 1 wherein 
the network-transport layer is a TCP/IP stack coupled to a 
first network through a first media-access controller and 
coupled to a second network through a second media-access 
controller, the client-side application-classifier further com- 25 
prising: 

a network enhancer, coupled between the network- 
transport layer and the first and second media-access 
controllers, for intercepting network packets and 
extracting routing information including source and 30 
destination network addresses; and 
a route table, coupled to the network enhancer, for storing 

the routing information for the network packets; 
the examiner coupled to the route table to determine a 
source address of either the first media-access control- 35 
ler or of the second media-access controller when the 
source address is not available from the upper interface, 
whereby source addresses for clients with two network 
connections is obtained by the network enhancer below the 
TCP/IP stack. 

8. A computer-implemented method for classifying net- 
work flows from a client, the method comprising: 

calling a socket function for opening or transmitting data 
through a socket-connection for connecting a high- 45 
level application to a remote machine on a network, the 
socket function being a function in an applications- 
programming interface (API) used by high-level appli- 
cations to access the network; 

activating an extensible service provider before the data is 5Q 
sent from the socket function to a lower network- 
transport layer, wherein the data is intercepted by the 
extensible service provider, the extensible service pro- 
vider for evaluating filters to determine which plugins 
need to be executed; S5 

activating an application-classifier plugin attached to the 
extensible service provider before the data is sent to the 
network-transport layer; 

collecting statistical information including a name of the 
high-level application generating the data, a user name, 60 
a timestamp, and a number of bytes transmitted when 
the application-classifier plugin is activated; 

consolidating the statistical information collected by the 
application-classifier plugin in application-classifier 
tables; and 65 

sending the statistical information to a policy server on a 
remote machine on the network, wherein the policy 
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server prioritizes the data using the name of the high- 
level application obtained from the application- 
classifier plugin on the client, 
whereby the policy server prioritizes network data based 
on names of high-level applications obtained from the 
application-classifier plugin on the client. 

9. The computer-implemented method of claim 8 wherein 
the step of sending the statistical information comprises: 

searching the application-classifier tables for matching 
entries having a source and a destination IP address that 
match a source and a destination IP address that the 
policy server obtained by examining a network packet, 
the network packet not containing the name of the 
high-level application; and 

reading the name of the application from the matching 
entries and sending the name of the high-level appli- 
cation to the policy server as the high-level application 
that generated the network packet examined by the 
policy server, 

wherein the policy server prioritizes network traffic based on 
high-level applications rather than low-level IP addresses. 

10. The computer-implemented method of claim 9 further 
comprising: 

generating an event object when the application-classifier 
plugin is activated, the event object indicating a type of 
network activity performed by the socket function, the 
event object containing the statistical information; 

sending the event object to the application-classifier 
tables, the statistical information being added to the 
application-classifier tables. 

11. The computer- implemented method of claim 10 fur- 
ther comprising: 

finding bandwidth-hogging applications by reading byte- 
count fields in the application-classifier tables and 
comparing the byte-count fields to a threshold, 

wherein applications with network flows having byte- 
counts above the threshold are identified as high- 
bandwidth applications. 

12. The computer-implemented method of claim 11 fur- 
ther comprising: 

using the timestamp in the statistical information and the 
number of byte transmitted to determine a rate of byte 
transfer; 

storing the rate of byte transfer in the application- 
classifier tables. 

13. The computer-implemented method of claim 8 
wherein the application-classifier plugin is transparent to 
high-level applications, the application-classifier plugin per- 
forming low-level network services. 

14. A computer-program product comprising: 

a computer-usable medium having computer-readable 
program code means embodied therein for classifying 
network traffic according to high-level application 
name, the computer-readable program code means in 
the computer-program product comprising: 
socket means for receiving data for transmission over a 
network, the data from a high-level application that 
uses a high-level library of socket-functions for 
sending the data to the socket means; 
transport means for sending the data to a lower-level 
network-transport layer, the lower-level network- 
transport layer for formatting the data for transmis- 
sion over the network; and 
extensible service provider means, coupled to the 
socket means and to the transport means, for acti- 
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vating a application-classifier plugin when the data is 
sent (o the transport means, the extensible service 
provider means further for activating other plugins; 
the application-classifier plugin including means for 
collecting information about the data, the informa- 
tion including a name of the high-level application 
generating the data, a source address and a destina- 
tion address, and a timestamp; 
whereby the data is classified by the name of the high-level 
application generating the data sent to the network. 

15. The computer-program product of claim 14 wherein 
the compute r-rcadable program code means further com- 
prises: 

a consolidator, coupled to the application-classifier 
plugin, for storing the information collected in 
application-classifier tables with information collected 
for network data transmissions for other high-level 
applications, 

whereby the information is stored in the application- 
classifier tables. 

16'. The computer-program product of claim 15 wherein 
the computer- readable program code means further com- 
prises: 

reporting means, coupled to the consolidator, for receiv- 
ing requests from a policy server on a remote machine 
on the network, for reading the application-classifier 
tables and returning to the policy server the name of the 
high-level application from the application-classifier 
tables, 

whereby the policy server looks up the name of the 
high-level application sending the data to the network, 

17. The computer-program product of claim 16 wherein 
the request from the policy server includes source and 
destination IP addresses from data packets sent over the 
network from the socket means, but the data packets do not 
contain the name of the high-level application sending the 
data, 
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whereby the policy server cannot obtain the name of the 
high-level application from the data packets but only from 
the application-classifier tables. 

18. The computer-program product of claim 16 wherein 
5 the computer-readable program code means further com- 
prises: 

filtering means for comparing transmission information 
for the data from the socket means to predetermined 
10 transmission criteria, for indicating when a socket 
matches the predetermined transmission criteria; 
wherein the extensible service provider means only acti- 
vates the application-classifier plugin when the socket 
matches the predetermined transmission criteria. 
15 19. The computer-program product of claim 18 wherein 
the computer-readable program code means further com- 
prises: 

a blocking plugin, coupled to the extensible service pro- 
^ vider means, for blocking the data from being trans- 
mitted to the network; 
wherein the policy server determines which data is low- 
priority data by reading the names of high-level appli- 
cations from the application-classifier tables; 
25 wherein the blocking plugin blocks low-priority data from 
being transmitted on the network to reduce network 
traffic, the blocking plugin under control of the policy 
server, 

whereby the low-priority data is blocked at the source 
30 before being sent over the network. 

20. The computer-program product of claim 16 wherein 
the application-classifier plugin and extensible service pro- 
vider means are installed on a client machine, 
whereby the client machine collects the information for use 
35 by the policy server. 

* * * * * 
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A multiprocessor computer system comprises a plurality of 
network interfaces each adapted to be coupled to respective 
external networks for receiving and sending data packets to 
and from remote devices coupled to the external networks 
via a particular communication protocol. The multiprocessor 
computer system further comprises a plurality of symmetri- 
cal processors including a control processor and at least one 
switching processor. The switching processor further 
includes at least one network application executing thereon. 
The control processor further includes an operating system 
portion having a kernel memory and at least one network 
driver communicating with the plurality of network inter- 
faces. A buffer descriptor list is accessible by the network 
application and the network driver. The buffer descriptor list 
defines the status of buffers provided in the kernel memory 
that are used for temporary storage of data packets trans- 
ferred between the network application and the plurality of 
network interfaces via the network driver. Data packets 
received by the network interfaces from the external net- 
works directed to the network application are placed in 
selected ones of the buffers by the network driver for direct 
access by the network application. Similarly, data packets 
transmitted from the network application to the external 
networks are placed in other selected ones of the buffers for 
direct access by the network driver. 

23 Claims, 9 Drawing Sheets 
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USER-LEVEL DEDICATED INTERFACE FOR 
IP APPLICATIONS IN A DATA PACKET 
SWITCHING AND LOAD BALANCING 
SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to computer data 
communication networks, and more particularly, to a mul- 
tiprocessor computer architecture having plural switching 
modules for transferring data packets between computer 
networks and a control module for performing load balanc- 
ing to ensure efficient utilization of the computer networks 
in which a software interface is defined between the switch- 
ing module and the operating system for transferring data 
packets therebetween. 

2. Description of Related Art 

Computer networks are widely used as a way to commu- 
nicate messages between computers. The Internet is made up 
of more than 100,000 interconnected computer networks 
spread across over 100 countries, including commercial, 
academic and government networks. Originally developed 
for the military, the Internet has become widely used for 
academic and commercial research. Today, the Internet has 
become commercialized into a worldwide information 
highway, providing information on every subject known to 
humankind. Similarly, businesses and other entities have 
adopted the Internet paradigm as a model for their internal 
networks, or so-called "intranets." 

Messages transferred between computers within a net- 
work are typically broken up into plural data packets. Packet 
switching systems are used to route the data packets to their 
required destination and enable the efficient handling of 
messages of different lengths and priorities. Since each data 
packet includes a destination address, all packets making up 
a single message do not have to travel the same path. 
Instead, the data packets can be dynamically routed over the 
interconnected networks as circuits become available or 
unavailable. The destination computer receives the data 
packets and reassembles them back into their proper 
sequence to reconstruct the transmitted message. 

Internet computer networks generally use the TCP/IP 
communications protocol, which is an acronym for Trans- 
mission Control Protocol/Internet Protocol. The TCP portion 
of the protocol provides the transport function by breaking 
a message into smaller packets, reassembling the packets at 
the other end of the communication network, and re-sending 
any packets that get lost along the way. The IP portion of the 
protocol provides the routing function by giving the data 
packets an address for the destination network and client at 
the destination network. Each data packet communicated 
using the TCP/IP protocol includes a header portion that 
contains the TCP and IP information. Another communica- 
tion protocol used in communication between Internet com- 
puter networks is UDP/IP, in which UDP is an acronym for 
User Datagram Protocol. UDP is used in place of TCP in 
conditions when a reliable delivery is not required. For 
example, UDP/IP is often used for real-time audio and video 
traffic where lost data packets are simply ignored, because 
there is no time to retransmit. Since the computer networks 
connected to the Internet may use other communication 
protocols besides TCP/IP or UDP/IP, gateways arc used to 
convert data packets from these protocols into the other 
protocols. 

At a destination network, one or more routers may be 
utilized to receive incoming data packets and route the 
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packets to other internal networks such as local area net- 
works (LAN). The internal networks may further include 
servers that supply information to one or more clients. The 
servers are generally high-speed microcomputers, minicom- 

5 puters or even mainframes. In some cases, the clients are 
internal to the network (i.e., at the back-end), and the router 
acts as a conduit for communication of data packets between 
the clients and the outside world. The back-end servers may 
provide various application functions for the clients, such as 

10 a database server that maintains the databases and processes 
requests from clients to extract data from or update the 
databases. In other cases, the clients are external to the 
network (i.e., at the front-end), and the router acts as a 
conduit for communication of data packets between the 

15 clients and the back-end servers. For example, an Internet 
application server at the back-end may host Web applica- 
tions within the network that are accessed by clients outside 
the network. In still other cases, the clients are both internal 
and external to the network. The routers perform the func- 

2Q tions of switching data packets between the internal and 
external networks, and balancing the load placed upon the 
back-end servers of the internal network by distributing 
message packets between the back-end servers in the most 
efficient and expeditious manner. 

25 In view of the high volume of message traffic that they 
process and the relatively limited kinds of tasks that they 
perform, routers typically comprise dedicated switching 
processors having an architecture optimized to provide these 
functions. These conventional dedicated switching proces- 

30 sors include a control module and a switching module that 
are viewed by the external networks as a single network 
entity. A drawback of such dedicated switching processors is 
that they can be very expensive due in part because they are 
manufactured in relatively low volumes as compared with 

35 other general-purpose computer systems. Moreover, the 
software that provides the message routing and load balanc- 
ing functions must be written specifically for the dedicated 
switching processors, which further increases the cost of 
purchasing, operating and maintaining such systems. An 

40 additional drawback of dedicated switching processors is 
that most modifications to their functionality require a 
hardware change, which is typically more expensive and 
difficult than a software change. 

A further disadvantage of dedicated switching processors 

45 is that it is cumbersome to communicate data packets 
between the switching module and the control module. 
Generally, the control module communicates with the 
switching module through special internal interfaces thai 
add overhead to both the control module and the switching 

50 module, and is thus undesirable. For example, the control 
module may include network applications that operate at the 
user level, and data input and output for the network 
applications is handled at the operating system level. The 
operating system communicates with the network devices 

55 and issues interrupts to the network applications at the user 
level to indicate the receipt of data. These conventional 
systems are inefficient since processing of the network 
applications is stopped each time an interrupt is issued, and 
the involvement of the operating system further reduces the 

60 efficiency of the network applications. 

It would therefore be very desirable to provide the mes- 
sage routing and load balancing functions of a network 
router within a general-purpose symmetrical multiprocessor 
(SMP) computer system. Such general-purpose multiproces- 

65 sor computer systems are less expensive than conventional 
systems due to their larger volume production, and changes 
to their functionality can be readily accomplished by modi- 
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fying their software rather than their hardware. It would 
additionally be desirable to provide network applications 
operating on a general-purpose multiprocessor computer 
system direct access to the network interfaces and to run the 
network applications on a dedicated processor which is not 5 
interrupted. Certain applications such as Internet telephony 
or fax applications would particularly benefit from such 
direct network access. 

SUMMARY OF THE INVENTION 

In accordance with the teachings of the present invention, 10 
a data packet switching and server load balancing device is 
provided by a general-purpose multiprocessor computer 
system. The general-purpose multiprocessor computer sys- 
tem comprises a plurality of symmetrical processors coupled 
together by a common data bus, a main memory shared by 15 
the processors, and a plurality of network interfaces each 
adapted to be coupled to respective external networks for 
receiving and sending data packets via a particular commu- 
nication protocol, such as Transmission Control Protocol/ 
Internet Protocol (TCP/IP) or User Datagram Protocol 20 
(UDP). 

More particularly, a first one of the processors is adapted 
to serve as a control processor and remaining ones of the 
processors are adapted to serve as data packet switching 
processors. The data packet switching processors are each 25 
coupled to at least one of the plurality of network interfaces. 
The control processor receives raw load status data from 
agents running on the back-end application servers and 
generates load distribution configuration data therefrom. 
The load distribution configuration data is stored in the main 30 
memory for access by the data packet switching processors. 
The switching processors route received ones of the data 
packets to a selected one of the external networks in accor- 
dance with information included in a header portion of the 
data packets and the load distribution configuration data. 35 
The switching processors perform periodic polling of cor- 
responding ones of the network interfaces to detect a 
received one of the data packets therein. In addition, the 
switching processors re-write the routing information 
included in the header portion of the data packets to reflect 40 
the selected one of the external networks. 

In an embodiment of the invention, a multiprocessor 
computer system comprises a plurality of network interfaces 
each adapted to be coupled to respective external networks 
for receiving and sending data packets to and from remote 45 
devices coupled to the external networks via a particular 
communication protocol. The multiprocessor computer sys- 
tem further comprises a plurality of symmetrical processors 
including a control processor and at least one switching 
processor. The switching processor further includes at least 50 
one network application executing thereon. The control 
processor further includes an operating system portion hav- 
ing a kernel memory and at least one network driver 
communicating with the plurality of network interfaces. A 
buffer descriptor list is accessible by the network application 55 
and the network driver. The buffer descriptor list defines the 
status of buffers provided in the kernel memory that are used 
for temporary storage of data packets transferred between 
the network application and the plurality of network inter- 
faces via the network driver. Data packets received by the 60 
network interfaces from the external networks directed to 
the network application are placed in selected ones of the 
buffers by the network driver for direct access by the 
network application. Similarly, data packets transmitted 
from the network application to the externa] networks are 65 
placed in other selected ones of the buffers for direct access 
by the network driver. 
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A more complete understanding of the software interface 
between switching and control modules of a computer data 
packet switching and load balancing system will be afforded 
to those skilled in the art, as well as a realization of 
additional advantages and objects thereof, by a consider- 
ation of the following detailed description of the preferred 
embodiment. Reference will be made to the appended sheets 
of drawings, which will first be described briefly. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a network configuration 
having a load balancing and packet switching device in 
accordance with the present invention; 

FIG. 2 is a block diagram of a general-purpose symmetri- 
cal multiprocessor computer system adapted to provide the 
load balancing a packet switching device; 

FIG. 3 is a block diagram of the general -purpose multi- 
processor computer system configured to provide a switch- 
ing processor to perform network data packet switching and 
a control processor to perform network load balancing; 

FIG. 4 is a block diagram depicting communication of 
information between the control processor and one of the 
switching processors; 

FIG. 5 is a flow chart illustrating operation of the packet 
engine module of the switching processor; 

FIG. 6 is a flow chart illustrating operation of the packet 
filter module of the switching processor; 

FIG. 7 is a block diagram illustrating a first embodiment 
of the invention having a pseudo-interface between the 
control processor and switching processors through the 
internal switch; 

FIG. 8 is a block diagram illustrating a second embodi- 
ment of the invention having a pseudo -interface between the 
control processor and switching processors through a driver 
operating on the control processor; 

FIG. 9 is a block diagram illustrating the portions of a data 
packet; 

FIG. 10 is a block diagram illustrating a third embodiment 
of the invention having a user-level network interface for 
applications operating on the switching processor; 

FIG. 11 is a flow chart illustrating a process of initializing 
the switching processor for user-level access to the network 
interfaces; 

FIG. 12 is a flow chart illustrating a process of sending 
data packets to a network interface at the user level; and 

FIG. 13 is a flow chart illustrating a process of receiving 
data packets from a network interface at the user level. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

The present invention satisfies the need for a general- 
purpose multiprocessor computer system adapted to provide 
message routing and toad balancing functions for a com- 
puter network. In the detailed description that follows, like 
element numerals are used to describe like elements 
depicted in one or more of the figures. 

Referring first to FIG. 1, an exemplary network configu- 
ration using a load balancing and packet switching system 
10 of the present invention is illustrated. The network 
elements illustrated to the left of the load balancing and 
packet switching system 10 in FIG. 1 are referred to as the 
"back-end server" side of the network, and the network 
elements illustrated to the eight of the load balancing and 
packet switching system 10 arc referred to as the "client" 
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side of the network. On the client side of the network, the 
load balancing and packet switching system 10 is coupled 
through two separate network channels to an external net- 
work switch 13. The external switch 13 is coupled to client 
stations 7 .,-72, permitting communication between the client 
stations and the back-end server side of the network. The 
external switch 13 is further connected to the Internet (or an 
intranet) 8 servicing client stations 9i-9 2 through a router 6. 
On the back-end server side of the network, the load 
balancing and packet switching system 10 is coupled 
through two separate network channels to an internal net- 
work switch 11. The internal switch 11 is further coupled to 
back-end servers 5 1 -5 3 . Thus, data packets originated at the 
client side of the network, such as from client stations 9j-9 2 
or 7.[-7 2 , and directed to the back-end side of the network 
pass through the external switch 13 to the load balancing and 
packet switching system 10, which determines the routing of 
the data packets to the back-end servers 5^5-2 through the 
internal switch 11. Conversely, datar packets originated at 
the back-end side of the network and directed to the client 
side of the network follow the same path in reverse. 

As known in the art, a network switch is a device that 
cross connects network nodes or LAN segments and allows 
full bandwidth to pass between connected nodes. 
Alternatively, the internal or external switches 11, 13 could 
be provided by a network hub, which is a device that 
connects nodes by sharing the bandwidth between the con- 
nected nodes. Network switches are advantageous over 
network hubs in view of their greater capacity and speed. As 
also known in the art, a router is a device that routes data 
packets between networks. Routers read the network address 
in each transmitted data packet and make a decision on how 
to send it based on the most expedient route (traffic load, line 
costs, speed, bad lines, etc.). Alternatively, the router 6 may 
be provided by a network switch or hub. It should be 
appreciated that various alternative network configurations 
are anticipated, and moreover, that the numbers of clients, 
back-end servers and network channels shown in FIG. 1 are 
purely for the purpose of illustration and are not intended to 
limit the scope of the invention in any way. 

Referring now to FIG. 2, there is shown a general-purpose 
symmetrical multiprocessor (SMP) computer adapted to 
provide the load balancing and packet switching system 10 
of FIG. 1. The SMP computer includes N individual pro- 
cessors 24(3-24^ coupled to a common system bus 12. Each 
one of the N processors 24 0 -24^ has an associated cache 
memory ^^-25^ The processors 24 0 -24^ may be provided 
by 64-bit UltraSPARC microprocessors sold by Sun 
Microsystems, Inc. The SMP computer further includes a 
main memory 14 and a memory controller 15 coupled to the 
common system bus 12. The main memory 14 contains 
stored data and instructions accessible by each of the pro- 
cessors 24 0 -24^ with the memory controller 15 controlling 
individual accesses to the main memory. As known in the 
art, the cache memory 250-25^ bridges the main memory 14 
and the processors 240-24^.. The cache memory 2S Q -2S N is 
faster than the main memory 14 and allows instructions to be 
executed and data to be read at higher speed. Instructions 
and data are transferred to the cache memory 2S Q -25 N in 
blocks using a look-ahead algorithm. The more sequential 
the instructions in the routine being accessed, and the more 
sequential the order of the data being read, the more chance 
the next desired item will still be in the cache memory 
250-25^,, and the greater improvement in performance. It is 
anticipated that the cache memory 2S Q -2S S be comprised of 
static random access memory (SRAM) chips, while dynamic 
RAM (DRAM) chips arc used for main memory 14. 
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Alternatively, the cache memory 2S 0 -2S N may be provided 
directly onto the same chips as the corresponding processors 
24 0 -24„. 

An input/output (I/O) controller 16 is also coupled to the 

5 common system bus 12, and controls the transfer of data 
between the processors 2A 0 -2A N and peripheral devices. Id 
particular, the I/O controller 16 is coupled to a disk interface 
device 18 which controls exchanges of data between the 
processors 24 0 -2A N and one or more disk storage devices. 

10 The I/O controller 16 is also coupled to M network interface 
devices YI^YIm which each control exchanges of data 
between the processors 2A 0 ~2A N and external computer 
networks, clients or servers. Each one of the network 
interface devices 17^7^ include a receive queue in which 
received data packets are temporarily held while awaiting 

15 processing by the SMP computer, and a transmit queue in 
which transmitted data packets are temporarily held while 
awaiting communication to a computer network. It should 
be appreciated that the N number of processors 24 Q -24 N 
would generally be equal to or less than the M number of 

20 network interface devices \1-\1 M . Each of the M network 
interface devices 17^17^ may communicate with plural 
computer networks, clients or servers, using conventional 
network protocols such as Ethernet, Token Ring, Asynchro- 
nous Transfer Mode (ATM), etc. 

25 It should be appreciated that the SMP computer may 
further include a keyboard and monitor (not shown) to 
permit access by management information services (MIS) 
personnel, such as to perform diagnostics, routine 
maintenance, and administrative level tasks. As will be 

3Q further described below, the SMP computer is adapted to 
provide message routing and load balancing; functions that 
would not require any direct user interaction, and the key- 
board and monitor would therefore serve little use during 
ordinary operation of the computer system. However, cer- 

35 tain applications of the load balancing and message routing 
system do include user applications running on the SMP 
computer, and for such applications it should be appreciated 
that a keyboard and monitor would be necessary. It is 
anticipated that the SMP computer include a multitasking, 

40 multiprocessing operating system, such as the Solaris oper- 
ating system by Sun Microsystems, Inc. 

Referring now to FIG. 3, a block diagram of the general- 
purpose SMP computer configured to provide network data 
packet switching and load balancing functions is illustrated. 

45 In the load balancing and packet switching system 10, one 
of the plural processors 24(5-24^ of FIG. 1 serves as a 
control processor 42, and the remaining processors serve as 
switching processors 44, and 44 2 . The control processor 42 
and switching processors 44j and 44 2 each have access to a 

50 shared memory space 34, such as provided by a portion of 
the main memory 14 of FIG. 1. The control processor 42 
handles administrative and configuration functions for the 
load balancing and packet switching system 10, and also 
communicates with agents on the application servers to 

55 collect system load information. The control processor 42 
then performs complex calculations on the raw system load 
information and defines an optimum traffic load distribution. 
The traffic load distribution result is then written into the 
shared memory space for use by the switching processors 

so 44j and 44 2 . The switching processors 44 2 and 44 2 exclu- 
sively perform the packet switching tasks, and do not handle 
any other computing tasks. Although two switching proces- 
sors 44 j and 44 2 arc depicted in FIG. 3, it should be 
appreciated that any number of switching processors can be 

65 advantageously utilized. 

The switching processors 44^ and 44 ; are each coupled to 
plural network interfaces 37 J -37 3 , such as provided by the 
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network interfaces 17^17^ of FIG. 2. Each respective one 
of the switching processors 44 x and 44 2 poll corresponding 
ones of the plural network interfaces 37j-H 3 for incoming 
data packets 20 present on their respective receive queues. 
Particularly, switching processor 44! polls the receive queue 5 
of network interface 37.,, and switching processor 44 2 polls 
the receive queue of network interfaces 37 2 and 37 3 . Since; 
each of the switching processors 44., and 44 2 poll different 
ones of the network interfaces 37j— 37 3 , conflicts between 
the switching processors over received data packets is 1Q 
avoided. In contrast, each one of the switching processors 
44j and 44 2 can supply data packets to the transmit queues 
of each one of the network interfaces 37 I -37 3 , so that data 
packets can then be routed to any computer network coupled 
to the load balancing and packet switching system 10. 15 

FIG. 4 illustrates in greater detail the communication of 
information between the control processor 42 and one of the 
switching processors 44. The control processor 42 further 
includes several software modules to handle discrete control 
tasks, including a resource manager module 52 and a master 20 
module 54. The control processor 42 may further include 
specialized application program interfaces (API) that handle 
communication between these software modules. The 
resource manager module 52 receives raw data from the 
back-end application servers indicating their present load 25 
status. This raw data includes various factors, including the 
number of clients presently being served, the utilization 
rates of the CPU and memory of the application server 
processor, the average execution time, and the number of 
requests per second. The raw load data is then provided to 3o 
the master module 54, which synthesizes the data into a 
desired load distribution in accordance with a predetermined 
distribution algorithm. For example, the distribution algo- 
rithm may favor distribution of mcoming packets so that all 
servers have an even load, or alternatively, may favor 35 
distribution of incoming packets to certain servers having 
unique applications or processing capability, Such distribu- 
tion algorithms are well known in the art. It is also antici- 
pated that the resource manager module 52 can be provided 
as a separate device entirely external to the control processor 40 
42. 

The shared memory 34 further includes a routing table 62, 
a configuration table 64, and a connection table 66. The 
routing table 62 is a database that contains the current 
network topology, and is accessed by the switching proces- 45 
sor 44 in determining routing information for the received 
data packets. Specifically, the routing table 62 defines the 
addresses and interconnection pathways between the load 
balancing and packet switching device 10 and the networks 
connected thereto. A routing daemon 58 within the control 50 
processor 42 is a program that executes in the background to 
retrieve the information stored in the routing table 62 and 
maintains the status of the routing table 62 as changes are 
made to the configuration. As generally known in the art, the 
routing daemon 58 functions like an extension to the oper- 55 
ating system, and does not otherwise interact with the other 
modules of the control processor 42 or the switching pro- 
cessor 44 discussed above. 

The load distribution data synthesized by the master 
module 54 is stored in the configuration table 64. The 60 
configuration table includes two redundant memory buffers, 
identified in FIG. 4 as A and B. At any given time, one of the 
two memory buffers is the active buffer and the other is the 
back-up buffer. A memory pointer within the shared memory 
34 defines which one of the two buffers is currently the 65 
active buffer. The switching processor 44 obtains the current 
load distribution data from the active buffer. The master 
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module 54 of the control processor 42 periodically provides 
updated load distribution data to the shared memory 34 that 
is written to the back-up buffer. Thereafter, the memory 
pointer switches from the active to the back-up buffer so that 
the updated load distribution data is accessible to the switch- 
ing processor 44. This double buffering technique speeds up 
operation of the load balancing and packet switching system 
10 by enabling load data processing to occur concurrently 
with packet switching, and prevents potential conflicts 
between (he switching processor 44 and the control proces- 
sor 42 that both need access to the same memory space. 

The connection table 66 maintains a record of the TCP 
and UDP connections routed by each of the switching 
processors 44. As discussed above, the data packets received 
by the switching processors 44 each contain transport data in 
the header (i.e., TCP or UDP data) that defines how the data 
packets should be reassembled with other data packets to 
reconstruct complete messages, or connections. As shown in 
FIG. 9, the data packets 20 generally have an IP address 
which is provided in an IP header 20c to define the desti- 
nation device as known to the external computer networks. 
This external IP address may actually be different than the 
internal IP address of the back-end application server 
selected by the load balancing and packet switching system 
10. Accordingly, the entries of the connection table 66 map 
the external IP address to the internal IP address. Following 
the IP header 20c, a TCP (or UDP) header 20b contains the 
transport data. The data portion 20a of the data packet 20 is 
provided after each of the foregoing headers. Returning now 
to FIG. 4, a new entry is added to the connection table 66 
after a first data packet of a new connection is received. The 
transport data for each of the received data packets is 
provided to the connection table 66 by the switching pro- 
cessor 44. 

Once the IP address is translated by the connection table 
66, the switching processor 44 determines a Media Access 
Control (MAC) address using an address resolution protocol 
(ARP). According to the ARP, a remote network node 
desiring to transmit a data packet to another node transmits 
an ARP broadcast packet that is received by every node 
connected to the network. The receiving node responds with 
an ARP response packet that contains the MAC address of 
the receiving node. Thereafter, the remote network node 
uses the MAC address in a MAC header 20d of subsequent 
data packets. The remote network node then saves the MAC 
address in the ARP cache memory so that it won't need to 
send another ARP broadcast packet again. 

Like the control processor, the switching processor 44 
also includes software modules to handle discrete tasks, 
including a packet engine module 72 and a packet filter 
module 74. The packet engine module 72 communicates 
with the network interface 37 to periodically poll for the 
presence of data packets in the receive queue, and delivers 
packets to the transmit queue to be sent to the external 
networks. The packet filter module 74 reads the IP and 
TCP/UDP data in the packet header to determine how to 
route the data packet. The packet filter module 74 accesses 
the connection table 66 in the shared memory 34 to deter- 
mine whether a received packet is part of an existing 
connection or a new connection. Then, the packet filter 
module 74 accesses the configuration table 64 to determine 
the proper routing of the received data packet based on 
current load conditions and other factors. The switching 
processor 44 may further include specialized APIs that 
handle communication between these software modules. 

The flow chart of FIG. 5 illustrates the software process 
performed by the packet engine module 72 of FIG. 4. The 
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software process operates in a tight loop so as to minimize 
the latency of data packets waiting in the network interface 
receive queue. The process is initialized at step 100, during 
which the switching processor 44 performs certain start-up 
tasks, including checking the routing table 62 in the shared 5 
memory 34. It is anticipated that the load balancing and 
packet switching device 10 remain continuously in an opera- 
tional state, and so this initialization step may only be 
executed rarely. 

A first processing loop begins with step 102, in which the 10 
packet engine module 72 polls the network interface 37 
receive queue. At step 104, the packet engine module 72 
determines whether there are any data packets available at 
the receive queue. If no data packets are available, the packet 
engine module 72 changes to the next network interface 37 15 
at step 106. As discussed above, a single switching processor 
44 may be responsible for receiving incoming data packets 
from plural ones of the network interfaces. It should be 
appreciated, however, that if the switching processor 44 only 
has responsibility for one network interface 37, then this step 20 
106 may be bypassed. After step 106, the packet engine 
module 72 returns to step 102. This first processing loop will 
repeat indefinitely until a received data packet is detected at 
step 104. If a data packet is available in the network interface 
receive queue, a second processing loop begins at step 108 25 
at which the packet engine module 72 retrieves the data 
packet. Then, at step 110, the retrieved data packet is passed 
to the packet filter module 74 for routing (described below). 
Thereafter, at step 112, the packet engine module 72 deter- 
mines whether additional packets are present at the network 30 
interface receive queue. If additional packets are present, the 
packet engine module 72 returns to step 108 and the second 
processing loop is repeated. If no additional packets are 
present, the packet engine module 72 returns to step 106 and 
the next network interface is polled. 35 

The flow chart of FIG. 6 illustrates the software process 
performed by the packet filter module 74 of FIG. 4. The 
process is initialized at step 200, during which the switching 
processor 44 performs certain start-up tasks as in step 100 
discussed above. At step 202, the packet filter module 74 40 
begins processing of a data packet retrieved by the packet 
engine module 72 as discussed above. The packet filter 
module 74 reads the TCP/IP or UDP data from the header of 
the data packet in step 204. The TCP/IP or UDP data will 
determine the subsequent processing and routing of the data 45 
packet. At step 206, the packet filter module 74 determines 
from the TCP/IP or UDP data whether the data packet is a 
valid service entry. In other words, the packet filter module 
74 verifies that the data packet was properly routed to the 
load balancing and packet switching device 10, or whether 50 
it was routed improperly and received by the network 
interface in error. If the data packet is not a valid service 
entry, at step 208, the packet filter module 74 sends a TCP 
reset packet back to the originator of a TCP connection via 
the packet engine module 72 and the network interfaces, or 55 
simply discards the data packet of a UDP connection. 

Assuming that the data packet is a valid service entry, the 
packet filter module 74 determines at step 210 whether the 
data packet is a new connection with a client. The packet 
filler module 74 checks the transport data in the data packet 60 
header against the entries in the connection table 66 in the 
shared memory 34 to determine whether previous data 
packets have been received from the same client previously. 
If it is a new connection, then the packet filter module 74 
checks the configuration table 64 for the current load con- 65 
ditions to determine the routing of data packet. As discussed 
above, the packet filter module 74 may elect to send the data 
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packet to the application server having the lightest current 
load. Alternatively, the packet filter module 74 may send the 
data packet to a certain one of the application servers based 
on particular aspects of the data packet, e.g., the data packet 
is part of a connection requiring processing capability 
unique to one of the application servers, or the data packet 
specifically requests action by a particular application 
server. 

Once the packet filter module 74 determines which appli- 
cation server should receive the data packet, the packet filter 
module at step 216 re-writes the MAC address and option- 
ally re-writes the IP address and TCP/UDP port number in 
the header of the data packet to reflect the address of the 
selected application server. Then, at step 218, a new entry is 
made in the connection table 66 to reflect the new connec- 
tion. The packet filter module 74 then returns the modified 
data packet back to the packet engine module 72 at step 224 
for forwarding to the appropriate network interface 37. The 
packet filter module 74 then returns to step 202 to process 
the next available data packet. 

If it was determined at step 210 that the received data 
packet was not a new connection with the client, the packet 
filter module 74 determines at step 212 whether a corre- 
sponding entry in the connection table 66 exists. If there is 
no corresponding entry, a reset packet is sent for TCP 
connections or the packet is discarded for UDP connections 
at step 208. Conversely, if the connection table 66 has a 
corresponding entry for the data packet, then, at step 220, the 
packet filter module 74 re -writes the MAC address and 
optionally re-writes the IP address and TCP/UDP port num- 
ber to reflect the application server and application that is 
already servicing the connection. The packet filter module 
74 then returns the modified data packet back to the packet 
engine module 72 at step 224 for forwarding to the appro- 
priate network interface 37. The packet filter module 74 then 
returns to step 202 to process the next available data packet. 

Conventional dedicated switching processors include a 
control module and a switching module that are viewed by 
the external networks as a single network entity. The control 
module communicates with the switching module through 
special internal interfaces that add overhead to both the 
control module and the switching modules, and is thus 
undesirable. An advantage of the load balancing and packet 
switching system 10 of the present invention is that the 
control processor 42 and the switching processors 44,-44 2 
may be viewed as entirely separate logical networking end 
points even though they both reside within a single physical 
device. Therefore, external clients may communicate with 
applications running on the control processor 42 by sending 
data packets through the switching processors 44,~44 2 , 
which, in turn, route the data packets to the control proces- 
sor. The control processor 42 reverses the order to send data 
packets back to the external clients. 

A first alternative embodiment of the invention is pro- 
vided in FIG. 7, which illustrates a block diagram of a 
pseudo-interface between the control processor 42 and the 
switching processors 44,-44 2 . As discussed above with 
respect to FIG. 1, the load balancing and packet switching 
device 10 communicates on the client side through an 
external switch 13 and on the back-end server side through 
an internal switch 11. More particularly, the switching 
processor 44, communicates with the externa] switch 13 
through the network interface 37,, the switching processor 
44 2 communicates with the external switch 13 through the 
network interface 37 2 . Similarly, the switching processor 
44 2 communicates with the internal switch 11 through the 
network interface 37 3 , and the switching processor 44 2 
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communicates with the internal switch 11 through the net- 
work interface 37 4 . The control processor 42 also commu- 
nicates with the internal switch 11 through the network 
interface 37 0 . 

A virtual IP address is assigned to the network interface 
37 0 . When external devices on the client side of the network 
wish to communicate with the control processor 42, a data 
packet is transmitted through the external switch 13 to one 
of the switching processors 44j— 44 2 , with the IP header 20c 
of the data packet listing the virtual IP address as the 
destination. The switching processor 44 then processes the 
incoming data packet in the manner described above with 
respect to FIGS. 5 and 6. Specifically, the packet filter 
module 74 of the switching processor re-writes the IP header 
20c of the data packet to reflect the real IP address of the 
network interface 37 0 . The packet engine module 72 then 
routes the modified data packet to the internal switch 11 
through a corresponding one of the network interfaces 37. 
The internal switch 11 then sends the modified data packet 
to the network interface 37 0 which then delivers the data 
packet to the control processor 42. The process is reversed 
for responses sent by the control processor 42 back to the 
external device that originated the connection. The control 
processor 42 sends a data packet via the network interface 
37 0 having the real IP address through the internal switch 11 
to one of the switching processors 44. The switching pro- 
cessor 44 rc-writcs the IP address to the virtual IP address 
known to the external device. The modified data packet is 
then sent out by the switching processor 44 through the 
external switch 13. 

A second alternative embodiment of the invention is 
provided in FIG. 8, which illustrates a block diagram of a 
pseudo-interface between the control processor 42 and a 
switching processor 44. The control processor 42 actually 
operates at two levels in a time-shared manner, referred to as 
a user level and an operating system level. The user level 
comprises the systems accessible to the user, and may 
include one or more user application programs 51 executing 
thereon, such as an e-mail program, a server application, 
and/or an Internet browser. The resource manager 52 and 
master module 54 described above with respect to FIG. 4 
also execute in the user level. The operating system level, 
also known as the kernel, provides the basic services for the 
control processor 42 as well as the switching processor 44, 
such as activating the hardware directly or interfacing to 
another software layer that drives the hardware. 

As shown in FIG. 8, the operating system 48 further 
includes a protocol module 55, a pseudo-network driver 57, 
and a network driver 59. The protocol module 55 serves as 
a data interface for the user application programs 51. The 
protocol module 55 converts received data packets that are 
directed to one of the user application programs 51 from the 
TCP/IP or UDP/IP protocols into a format usable by the user 
application programs. Specifically, the protocol module 55 
strips off the MAC header 20d, IP header 20c, and TCP 
header 20b, leaving the data portion 20a of the data packet 
20 (see FIG. 9). The data portion 20a is then provided to the 
user application programs 51. Conversely, the protocol 
module 55 formats data sent out from the user application 
programs 51 into data packets in accordance with the 
TCP/IP or UDP/IP protocols, by adding the MAC header 
20d, IP header 20c, and TCP (or UDP) header 20i>. 

The network drivers 59 provide an interface between the 
hardware network interfaces 37 and the software switching 
processor 44. As illustrated in FIG. 8, the control processor 
42 docs not have a direct connection to the network drivers 
59. Instead, the pseudo-network driver 57 is configured to 
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appear to the user application programs 51 as a hardware 
network interface. The pseudo -network driver 57 may be 
provided by a STREAMS mechanism, which is a feature of 
a UNIX-based system that provides a standard way of 
dynamically building and passing messages up and down a 
message stack. Ordinarily, messages from a user application 
are passed "downstream" to the network driver at the end of 
the stack, and messages from the network driver are passed 
"upstream" to the user application. In the present invention, 
the pseudo-network driver 57 provides a message stack, that 
is accessed through the use of system calls issued by the user 
application programs 51 to communicate with remote 
devices through the pseudo-network driver 57. As will be 
further described below, a data packet storage area 68 within 
the shared memory 34 appears to the user application 
programs 51 as such a remote device. 

The interface daemon 53 is a program that executes in the 
background in the user level of the control processor 42 to 
communicate with the switching processor 44 and the 
pseudo -network driver 57 to initiate transfers of data packets 
therebetween. As described above with respect to FIGS. 5 
and 6, the switching processors 44 receive incoming data 
packets from remote devices through the network interfaces 
37. At step 204 of FIG. 6, the packet filter module 74 reads 
the MAC address and IP information from the header of a 
received data packet in order to determine routing of the data 
packet. If the packet switching processor 44 determines at 
step 204 that the intended destination for the data packet is 
one of the user applications 51 running on the control 
processor 42, the data packet is written into the data packet 
storage location 68 of the shared memory 34. The switching 
processor 44 then signals the interface daemon 53 of the 
availability of the data packet. The interface daemon 53 
moves the received data packet to the pseudo-network driver 
57. The received data packet is then processed through the 
protocol module 55 as if it were an incoming data packet 
received through an actual network interface. 

To send data packets that originate in one of the user 
applications 51 to a remote device, the foregoing process is 
reversed. More particularly, data packets from the user 
applications 51 are passed to the pseudo-network driver 57, 
and the interface daemon 53 monitors the pseudo -network 
driver for data packets. Once a data packet arrives at the 
pseudo-network driver from the user application 51, the 
interface daemon 53 reads the data packet and places it in the 
data packet storage location 68 of the shared memory 34. 
Then, the interface daemon 53 signals the switching pro- 
cessor 44 of the availability of the data packet in the data 
packet storage location 68. The switching processor 44 then 
retrieves the data packet from the shared memory 34, and 
routes the data packet to one of the network interfaces 37 in 
the same manner as described above. As a result, remote 
devices can communicate with user applications 51 running 
on the control processor 42 even though the control proces- 
sor does not have a direct connection to a network interface. 
The user applications 51 executing on the control processor 
42 think they arc communicating directly with actual net- 
work interfaces. 
As discussed above, user applications ordinarily operate 
60 at the user level, and data input and output is handled at the 
operating system level. The operating system communicates 
with the network devices and issues interrupts to the net- 
work applications at the user level to indicate the receipt of 
data. These conventional systems are inefficient since pro- 
65 cessing of the network applications is stopped each time an 
interrupt is issued, and the involvement of the operating 
system further reduces the efficiency of the user applica- 
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tions. It would therefore be desirable to give the network 
applications direct access to the network interfaces and to 
run tbe network applications on a dedicated processor which 
is not interrupted. Certain network applications such as 
Internet telephony or fax applications would particularly 5 
benefit from such direct network access. 

A third embodiment of the invention is provided at FIG. 
10, which illustrates a block diagram of a user-level network 
interface for applications running on the switching processor 
44. The user-level network interface overcomes the ineffi- 10 
ciencies of the conventional systems discussed above. In 
FIG. 10, the switching processor 44 has certain network 
applications 65 running thereon, including the packet 
switching functions described above. The network applica- 
tions 65 and the packet switching program have direct 15 
access to a list of buffers in the kernel memory 63. In an 
Ethernet network, each network interface 37 has a list of 
buffers associated with it. These buffers can be used to 
transmit data as well as receive data. A network driver 59 on 
the operating system 48 communicates with the network 20 
interface 37 in the manner described previously, and also has 
access to the buffer list in the kernel memory 63. 

In particular, the buffer list includes descriptors that 
identify the address of each buffer within the kernel memory 
63, the length of the data stored in the buffer, and an 25 
ownership identification of the buffer (i.e., whether tbe 
buffer is presently "owned" or controlled by the network 
interface hardware or the network application software). The 
network interface 37 circles through the buffer list in the 
kernel memory 63 to access the buffers in order to send or 30 
receive data as necessary. Similarly, the network applica- 
tions 65 on the switching processor 44 circle through the list 
of buffers to process the data. If the network interface 37 
transmits data from a particular buffer, the network appli- 
cations 65 reclaim the buffer and return it to a free buffer 35 
pool. Conversely, if the network interface 37 has just 
received data and placed the data in a particular buffer, the 
network applications 65 process the data. 

FIGS. 11-13 illustrate the processes performed by the 
switching processor 44 to initiate the direct user access to tbe 40 
network interfaces, to send data packets to the network 
interfaces, and to receive data packets from the network 
interfaces. As shown in FIG. 11, the switching processor 44 
is initiated in a process beginning at step 300. At step 301, 
all interrupts to the switching processor 44 are disabled so 45 
that the switching program and any network application 
programs are run exclusively on the processor. Any inter- 
rupts from any device are thereafter delivered to the control 
processor 42. Next, at step 302, the kernel memory 63 that 
is to be shared between the network interfaces 37 and tbe 50 
network applications 65 operating on the switching proces- 
sor 44 is allocated. All the buffers within the kernel memory 
63 are mapped to all of the network interfaces 37 so that any 
buffer can be used to transmit or receive data through any of 
the network interfaces. Lastly, at step 303, the network 55 
interfaces' registers and buffers are mapped to the network 
applications 65. This enables the network applications 65 to 
directly control the network interfaces 37 by changing the 
content of the registers and to perform read/write operations 
from/to the buffers directly. eo 

Once the switching processor 44 is initiated in this 
manner, all data accesses from/to the network interfaces 
operate like conventional memory read/write operations by 
the network applications. High efficiency results from the 
fact that the network applications 65 and the switching 65 
program run on a single thread on a dedicated, non- 
interruptable processor. Also, there is no context switching 
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since the programs running on the switching processor 44 
are isolated as a separate group that is not available to any 
other processes or threads in the multiprocessor system. 

The process of sending data from one of the network 
applications 65 to the network interface 37 is illustrated in 
FIG. 12, and begins with step 320. At step 321, the network 
application 65 gets the next available buffer from the free 
buffer pool. The free buffer pool may be maintained as a 
table within the kernel memory 63. The network application 
65 then writes the data to be transmitted in the form of a data 
packet into the identified buffer at step 322, and changes the 
"ownership" of the buffer to the network interface 37 at step 
323. At step 324, the network application 65 indicates to the 
network interface 37 that a buffer contains data ready to be 
transmitted. At step 325, the network application 65 peri- 
odically checks to see if the data has been transmitted. Once 
the data has been transmitted, the network application 65 
returns the buffer to the free pool at step 326. At step 327, 
the network application 65 returns to performing other tasks. 

The process of receiving data from the network interface 
37 to one of the network applications 65 is illustrated in FIG. 
13, and begins with step 340. At step 341, the network 
application 65 passes a list of available buffers from the free 
buffer pool to the network interface 37. At step 342, the 
network application 65 checks the status of the network 
interface 37 to sec if data has been received. If no data has 
been received, step 343 causes the program to loop back and 
repeat step 342. If data has been received by the network 
interface 37, the network application 65 identifies the buffer 
into which the data has been received by checking the 
ownership bit at step 344. The network application 65 next 
verifies that valid data was received into the buffer at step 
345, and if the data is not valid then the program returns to 
step 342. Conversely, if the received data is valid, then the 
network application 65 processes the data at step 346. 
Thereafter, the network application 65 returns the buffer to 
the free buffer pool at step 347. At step 348, the network 
application 65 returns to performing other tasks. 

Having thus described a preferred embodiment of a 
computer data packet switching and load balancing system 
using a general-purpose symmetrical multiprocessor 
architecture, it should be apparent to those skilled in the art 
that certain advantages of the aforementioned system have 
been achieved. It should also be appreciated that various 
modifications, adaptations, and alternative embodiments 
thereof may be made within the scope and spirit of the 
present invention. The invention is further defined by the 
following claims. 

What is claimed is: 

1. A multiprocessor computer system, comprising: 

a plurality of network interfaces each adapted to be 
coupled to respective external networks for receiving 
and sending data packets to and from remote devices 
coupled to said external networks via a particular 
communication protocol; 

& plurality of symmetrical processors including a control 
processor and at least one switching processor, said at 
least one switching processor further including at least 
one network application executing thereon, said control 
processor further including an operating system portion 
that includes a kernel memory and at least one network 
driver communicating with said plurality of network 
interfaces; and 

a buffer descriptor list accessible by said at least one 
network application and said at least one network 
driver, said buffer descriptor list defining status of 
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buffers provided in said kernel memory used for tem- 
porary storage of data packets transferred between said 
at least one network application and said plurality of 
network interfaces via said network driver; 
wherein, data packets received by said network interfaces 5 
from said external networks directed to said at least one 
network application are placed in selected ones of said 
buffers by said network driver for direct access by said 
at least one network application, and data packets 
transmitted from said at least one network application 10 
to said external networks are placed in other selected 
ones of said buffers for direct access by said network 
driver. 

2. The multiprocessor computer system of claim 1, 
wherein said at least one switching processor further 15 
includes stored instructions to be executed by said at least 
one switching processor, said stored instructions comprising 
the steps of: 

disabling interrupts directed to said at least one switching 
processor; and 20 

circling through said buffer descriptor list to monitor 
ownership status of said buffers. 

3. The multiprocessor computer system of claim 2, 
wherein said stored instructions further comprise: ^ 

for receiving a data packet from said external networks, 
identifying one of said buffers reflecting ownership by 
one of said network applications, processing a data 
packet stared in said one of said buffers, and restoring 
said one of said buffers to a free status. 30 

4. The multiprocessor computer system of claim 2, 
wherein said stored instructions further comprise; 

for transmitting a data packet from said at least one 
network application, identifying a free one of said 
buffers, storing a data packet in said free buffer, and 35 
changing ownership status of said free buffer to reflect 
ownership by one of said plurality of network inter- 
faces. 

5. The multiprocessor computer system of claim 1, 
wherein said control processor receives raw load status data 40 
from said external networks and generates load distribution 
configuration data therefrom, said load distribution configu- 
ration data being accessible by said at least one switching 
processor, said at least one switching processor routing 
received ones of said data packets not directed to said at least 45 
one network application lo a selected one of said external 
networks in accordance with information included in a 
header portion of said data packets and said load distribution 
configuration data. 

6. The multiprocessor computer system of claim 1, 50 
wherein said at least one switching processor further pro- 
vides periodic polling of corresponding ones of said network 
interfaces for detecting received ones of said data packets 
therein. 

7. The multiprocessor computer system of claim 5, 55 
wherein said at least one switching processor further 
re-writes said routing information included in said header 
portion of said data packets to reflect said selected one of 
said external networks. 

8. The multiprocessor computer system of claim 5, further 60 
comprising a shared memory including a connection table 
reflecting status of previously received ones of said data 
packets. 

9. The multiprocessor computer system of claim 8, 
wherein said at least one switching processor accesses said 65 
connection table to determine correspondence between a 
received one of said data packets and said previously 
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received ones of said data packets in determining said 
selected one of said external networks. 

10. The multiprocessor computer system of claim 8, 
wherein said memory further comprises a configuration 
table containing said load distribution configuration data. 

11. The multiprocessor computer system of claim 5, 
wherein said at least one switching processor further 
includes a switching program having an engine module 
containing stored instructions to be executed by said at least 
one switching processor, said stored instructions comprising 
the steps of: 

polling a first one of said network interfaces for presence 
of a received data packet; 

if a received data packet is present at said first one of said 
network interfaces, routing said received data packet to 
said selected one of said external networks; and 

if a received one of said data packets is not present at said 
first one of said network interfaces, polling another one 
of said network interfaces for presence of a received 
data packet. 

12. The multiprocessor computer system of claim 8, 
wherein said at least one switching processor further 
includes; a filter module having stored instructions to be 
executed by said at least one switching processor, said stored 
instructions comprising the steps of: 

reading routing information from said header portion of 
said data packet; 

accessing said load distribution configuration data stored 
in said shared memory; 

selecting said selected one of said external networks 
based on said routing information and said load distri- 
bution configuration data; 

modifying said data packet by re-writing said routing 
information to reflect said selected one of said external 
networks; and 

sending said modified data packet to one of said plurality 
of network interfaces corresponding to said selected 
one of said external networks. 

13. The multiprocessor computer system of claim 12, 
wherein said stored instructions of said filter module further 
comprises the steps of: 

reading transport information from said header portion of 
said data packet; and 

accessing connection status data stored in a connection 
table of said shared memory reflecting status of previ- 
ously received -ones of said data packets, wherein, if 
said transport information indicates that said data 
packet corresponds to a previously received data 
packet, then said selecting step further comprises 
selecting said selected one of said external networks 
based on routing of said previously received data 
packet 

14. In a multiprocessor computer system comprising a 
plurality of symmetrical processors and a plurality of net- 
work interfaces each adapted to be coupled to respective 
external networks for receiving data packets from remote 
devices and sending data packets thereto via a particular 
communication protocol, a method for operating said com- 
puter system comprises the steps of: 

configuring one of said plurality of processors as a control 
processor and others of said plurality of processors as 
switching processors, said control processor further 
having an operating system portion that includes a 
kernel memory and at least one network driver com- 
municating with said plurality of network interfaces, at 
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least one of said switching processors further including 
a network application executing thereon; 

providing a buffer descriptor list accessible by said net- 
work application and said at least one network driver, 
said buffer descriptor list defining status of plural 5 
buffers provided in said kernel memory used for tem- 
porary storage of data packets transferred between said 
network application and said plurality of network inter- 
faces via said network driver; 

placing incoming data packets received by said network 10 
interfaces from said external networks directed to said 
at least one network application in selected ones of said 
buffers by said network driver for direct access by said 
network application; and 

placing outgoing data packets transmitted from said at 
least one network application to said external networks 
in other selected ones of said buffers for direct access 
by said network driver. 

15. The method of claim 14, further comprising the steps 2n 

of: 

disabling interrupts directed to said at least one switching 

processor; and 
circling through said buffer descriptor list to monitor 

ownership status of said buffers. 25 

16. The method of claim 14, wherein said step of placing 
incoming data packets further comprises: 

identifying one of said buffers reflecting ownership by 
said network application, processing a data packet 
stored in said one of said buffers, and restoring said one 30 
of said buffers to a free status. 

17. The method of claim 14, wherein said step of placing 
outgoing data packets further comprise: 

identifying a free one of said buffers, storing a data packet 
in said free buffer, and changing ownership status of 



said free buffer to reflect ownership by one of said 
plurality of network interfaces. 

18. The method of claim 14, further comprising the steps 

of: 

providing load data to said control processor regarding 
load status of said external networks; 

generating load distribution configuration data from said 
load data using said control processor and providing 
said load distribution configuration data for access by 
said data packet switching processors; and 

routing a received data packets not directed to said 
network application using said switching processors to 
a selected one of said external networks in accordance 
with information included in a header portion of said 
data packet and said load distribution configuration 
data. 

19. The method of claim 18, further comprising the step 
of re-writing said routing information included in said 
header portion of said data packets by said switching pro- 
cessors to reflect said selected one of said external networks. 

20. The method of claim 18, further comprising the step 
of providing a connection tabic reflecting status of previ- 
ously received ones of said data packets. 

21. The method of claim 20, further comprising accessing 
said connection table by said switching processors to deter- 
mine correspondence between said received one of said data 
packets and said previously received ones of said data 
packets in determining said selected one of said external 
networks. 

22. The method of claim 18, further comprising providing 
a configuration table containing said load distribution con- 
figuration data, 

23. The method of claim 14, wherein said particular 
communication protocol further comprises TCP/IP. 
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FIG. 11 
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MULTI-STAGE DATA FILTERING SYSTEM 
EMPLOYING MULTIPLE FILTERING 
CRITERIA 

FIELD OF THE INVENTION 

The present invention relates to a data filtering system. 
More specifically, the present invention provides a system 
capable of filtering data in multiple stages, with each stage 
of filtering using different filtering criteria. 

BACKGROUND 

The increased use of networks (such as the Internet) and 
networking technology has increased the quantity of data 
presented to individuals and organizations on a day-to-day 
basis. This data may be in the form of advertisements, news 
articles, and other information from any number of data 
sources. Although much of this data may be of interest to 
particular individuals and organizations, a significant por- 
tion of the data is generally of little or no value to the 
recipient. For example, the data may be related to a subject 
that is of no interest to the recipient or related to a type of 
product that the recipient does not use and does not intend 
to purchase. 

Existing systems are available for selecting data to be 
provided to a particular user based on criteria that is supplied 
actively or passively by the user. These existing systems 
perform various filtering operations on a server to select the 
data to be provided to a particular user. Since these filtering 
operations are performed on a centralized server, the server 
must contain the necessary filtering criteria to select the data. 
These existing systems limit the effectiveness of the filtering 
operation because certain criteria necessary for proper fil- 
tering is confidential or private to the user and is not 
disclosed to the server. Since the server does not have this 
private information, it cannot adequately filter out all of the 
irrelevant data. For example, if a user does not indicate their 
age to the server, then the server cannot filter data that is 
directed at a particular age group. As a result, the user 
receives all data regardless of whether the data is relevant lo 
a person in the user's age group. 

Since the server is unable to filter data based on private 
criteria not provided to the server by the user, the user may 
receive a significant amount of irrelevant data. This irrel- 
evant data is time consuming to review and creates a 
distraction from the user's normal work or activities. Since 
many servers that provide data filtering operations may not 
be trustworthy with respect to private information, many 
users are unwilling to provide private information to these 
servers. As a result, the user receives a significant amount of 50 
unwanted data. 

Other known systems for filtering data perform all filter- 
ing operations on a client. These systems provide all data 
from all sources to the client, which then filters the data 
based on information provided by the user of the client. This 
approach significantly increases the amount of data received 
by the client and increases the bandwidth or transmission 
time required to transmit the data to the client from the data 
sources. The increase in data received by the client also 
increases the Local storage requirements. 60 

It is therefore desirable to provide a unified data filtering 
system capable of filtering out data that is not relevant to a 
particular user, without compromising the user's privacy. 

SUMMARY OF THE INVENTION 65 

The present invention is related to a system for filtering 
data in multiple stages without exposing private information 



to untrusted servers. In one embodiment of the invention, a 
first filter criteria is provided to a first device, which uses the 
first filter criteria to generate a first set of filtered data. The 
first set of filtered data is received from the first device and 
5 filtered based on a second filter criteria, which is different 
from the first filter criteria. The filtering of the data received 
from the first device generates a second set of filtered data. 

In a particular embodiment of the invention, the first filter 
criteria and the second filter criteria are included in a profile 
10 data set. 

In another embodiment of the invention, the first filter 
criteria contains public profile data and the second filter 
criteria contains private profile data. 

Embodiments of the invention provide a profile data set 
that contains elements associated with a particular class of 
data recipients. 

Other embodiments provide a profile data set that contains 
elements associated with a particular data recipient role. 

In an embodiment of the invention, the first device is an 
untrusted filtering device and the second device is a trusted 
filtering device. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example in 
the following drawings in which like references indicate 
similar elements. The following drawings disclose various 
embodiments of the present invention for purposes of illus- 
tration only and are not intended to limit the scope of the 
invention. 

FIG. 1 illustrates an embodiment of a multi-stage data 
filtering system. 

FIG. 2 is a flow diagram illustrating an embodiment of a 
procedure for performing multi-stage data filtering. 

FIG. 3 is a flow diagram illustrating another embodiment 
of a procedure for performing multi-stage data filtering. 

FIG. 4 illustrates an embodiment of a profile data set for 
use with the present invention. 

FIG. 5 illustrates exemplary profile data elements related 
to user-specific information. 

FIGS. 6Aand 6B illustrate exemplary server filter criteria 
and client filter criteria generated from the profile data 
elements shown in FIG. 5. 

FIG. 7 illustrates another embodiment of a multi-stage 
data filtering system. 

FIGS. 8A-8C illustrate exemplary filter criteria for use in 
the multi-stage data filtering system shown in FIG. 7. 

FIG. 9 illustrates another embodiment of a multi-stage 
data filtering system. 

FIG. 10 illustrates an embodiment of a computer system 
that can be used with the present invention. 

FIG. 11 illustrates an embodiment of a computer-readable 
medium containing various sets of instructions, code 
sequences, configuration information, and other data used by 
a computer or other processing device. 

DETAILED DESCRIPTION 

The following detailed description sets forth numerous 
specific details to provide a thorough understanding of the 
invention. However, those of ordinary skill in the art will 
appreciate that the invention may be practiced without these 
specific details. In other instances, well-known methods, 
procedures, protocols, components, and circuits have not 
been described in detail so as not to obscure the invention. 
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The present invention is related to a system capable of ing data may pass through filter 20, such that filtered data 22 

filtering data for a particular user (also referred to as a data contains all incoming data. Upon completion of the filtering 

recipient) without compromising that user's privacy. The operation performed by filter 20, filtered data 22 is provided 

invention provides a unified data filtering process such that to client 14 using communication link 16. 

data filtering is performed in multiple stages, with different 5 CUent 14 contains a profile dala ^ 2 4, which includes 

filtering criteria used at each stage. In a first stage, data ^ 2g Jq mi& embodimeatj client 14 is 

filtering can be performed by a server using non-private the clieQt ^ mdude 

filtering eaten.. The data that passes through ' ^tcr « Ac information thM is not shared with server 10. Profile 

first stage continues to another data filter at a second stage. *, ^ . A . „ , t . t , ... 

The second stage of filtering may be performed by a client in data s f 24 contains »■! Profite dala assorted with a 

or a more trusted server, thereby allowing filtering criteria 10 P artlcu , lar user or orgamzahoa This profile . data is used I to 

... -.(■.• u 4 *u generate server filter criteria 18 and client filter criteria 26. 

containing private information about the user or organiza- * . t . . 1 fi1 j , t 

jl l. re, • 4 u . i- j j In the embodiment shown in FIG. 1, profile dala set 24 

Uon.Any number of filtering stages may be utilized, depend- ^ . _ . . i0 , *\ . 

, c j i 4 j contains server filter cntena 18 and client falter criteria 26. 

ing on the number of servers or other devices located _ _ ... ^ c , , , . , , 

u * *u ^ . ™ j il ^ * o„ In alternate embodiments, profile data set 24 may include 

between the data source and the data recipient. By limiting 1C ■ . f . , , - J 

„ Cli . . „ . . . i „ 15 filter criteria associated with a particular class of users or a 

private filtering criteria to trusted servers or clients, a . . , . . r , , j . 

• a * _ * f <„j ^ * v i ™ „„ t u„,.i particular role that a user performs. Additional details 

significant amount of unwanted data is eliminated without v v 

^ ,, , regarding profile data sets are provided below with respect 

compromising the user s privacy. to FIGS 4-6 

Throughout this detailed description of the invention, ^ 0 , ,■ £11 

various embodiments are discussed that include a client m Cherit " also md u d eS a filter 28 that applies chen filter 

coupled to one or more servers. The teachings of the present c " tcria 26 to filtered data 22 received from server 10 or, 

invention are applicable to any type of device containing a communication link 16. Filter 28 generates a set of filtered 

processor or a controller capable of executing instructions. data 3 °> representing the incoming data that meets both 

Thus, the clients and servers discussed herein can be any server filtcr cntcria 18 and chent Alter criteria 26. Filtered 

type of computing device, including desktop or laptop « data 30 is then provided to the user of client 14 for viewing 

computers, personal digital assistants (PDAs), set-top boxes, or olher processing. To maintain the privacy of the infor- 

or devices containing embedded controllers or embedded matl0n contained in the profile data set, the results of the 

processors. Further, any type of communication link and filterin S P rocess at an y particular level of trust are not 

communication medium can be used to communicate infor- P rovided t0 a device or mteruj S P roccss havin S a lowcr levcl 

mation between two or more devices. 30 °^ trust - 

Particular data filtering procedures are described below As shown in the filtering system of FIG. 1, profile data set 

that utilize a profile data set to generate filter criteria for 24 * contained in client 14. Thus, only the data that is public 

servers and clients. However, it will be appreciated that any 0- e -. not confidential or private) is shared with server 10. 

method or procedure for filtering data can be used with the The remaining filter cntena are stored on the client and is 

present invention. Further, any number of filtering param- 35 not exposed to or otherwise provided to the server. Thus, the 

eters or attributes may be used to filter data at any number sin S le profile data set 24 provides a unified system for 

of data filtering stages. Additionally, the present invention filtering incoming data on both server 10 and client 14. 

can be used with any type of data (e.g., text, graphics, The embodiment of FIG. 1 represents a unified two -stage 

product updates (such as software updates), or executable data filtering system. However, the teachings of the present 

instructions) and with data received from any data source or 40 invention may be applied to a data filtering system having 

sources. any number of data filtering stages. An example of a unified 

FIG. 1 illustrates an embodiment of a multi-stage data three-stage data filtering system is illustrated in FIG. 7 and 

filtering system. A server 10 receives incoming data on a discussed below. Additionally, FIG. 1 shows a single client 

communication link 12. Communication link 12 may be a 14 coupled to server 10. In other embodiments of the 

network communication link or any other link capable of 45 invention, a particular server may be coupled to multiple 

communicating data between two or more devices. Server clie nts and contain separate filter criteria for each client that 

10 communicates with a client 14 using a communication receives data from the server. 

link 16. Communication link 16 may be a link through a FIG. 2 is a flow diagram illustrating an embodiment of a 

network or any other link capable of propagating data procedure for performing multi-stage data filtering. The 

between server 10 and client 14. Communication links 12 50 procedure illustrated in FIG. 2 may be used, for example, 

and 16 may use any type of communication medium, such with the data filtering system illustrated in FIG. 1. At step 40, 

as, but not limited to, wires, fiber optic cables, or wireless a profile data set is generated and stored on a client (e.g., 

communication systems. client 14 in FIG. 1). Additional details regarding the profile 

Server 10 includes server filter criteria 18, which provides data set arc discussed below with reference to FIGS. 4-6 . At 

the filtering criteria used by a filter 20 to filter the incoming 55 step 42, the procedure determines the level of trust associ- 

dala. Server 10 may be an untrusted server with which users ated with a server (e.g., server 10 in FIG. 1). For example, 

are unwilling to share private information. In this situation, a server located inside (i.e., on the corporate side) of a 

server filter criteria 18 contains public information (i.e., firewall may have a high level of trust and security, but a 

public filtering criteria) that the user is willing to share with server located outside the firewall may be untrustworthy and 

the server. Additional details regarding server filter criteria 60 is assigned a low level of trust. The level of trust associated 

18 and the operation of filter 20 are provided below. Filter with a particular server determines the type of profile data 

20 generates filtered data 22 as a result of applying server that is shared with that server for data filtering purposes. If 

filter criteria 18 to the incoming data. Filtered data 22 is a level of trust is not assigned to a particular server, then the 

generally a subset of the incoming data received on com- server may be assigned a default level of trust (e.g., an 

munication link 12. However, in certain situations, filtered 65 untrusted server). 

data 22 is a null set of data if filter 20 removes (i.e., filters At step 44 of FIG. 2, the client transmits profile data 

out) all of the incoming data. In other situations, all incom- elements associated with the server's level of trust to the 
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server. These profile data elements are referred to as the 
server filter criteria. The server filter criteria is stored within 
the server (e.g., in a register or other data storage 
mechanism). The server filter criteria may be stored tempo- 
rarily or permanently. At step 46, the procedure determines 
whether incoming data was received by the server. If no data 
was received, the procedure returns to step 46 to repeatedly 
test for incoming data. As an alternative to repeated testing 
for incoming data, the procedure may use a "trigger" that 
causes the procedure to continue to step 48 when incoming 
data is detected. 

At step 48, the procedure filters the incoming data on the 
server using the server filter criteria. Step 50 transmits the 
filtered data, if any, from the server to the client. At step 52, 
the procedure filters data received by the client using the 
profile data elements associated with the client. These profile 
data elements are referred to as the client filter criteria. 
Finally, step 54 processes the filtered data, if any, generated 
by the client. This processing may include displaying the 
data to a user or notifying the user of the received data. If 
either the filtering performed by the server at step 48 or by 
the client at step 52 eliminates all data, then the procedure 
terminates without notifying the user. 

FIG. 3 is a flow diagram illustrating another embodiment 
of a procedure for performing multi-stage data filtering. The 
procedure illustrated in FIG. 3 may be used, for example, 
with the data filtering system illustrated in FIG. 1. The 
procedure of FIG. 3 is similar to the procedure discussed 
above with respect to FIG. 2, but transmits profile data 
elements to the server after the receipt of incoming data 
instead of prior to the receipt of incoming data. At step 60, 
a profile data set is generated and stored on the client. Step 
62 determines whether incoming data has been received by 
the server. If incoming data has not been received, then the 
procedure returns to step 62 to continue testing for incoming 
data. Alternatively, a "trigger" can be used that causes the 
procedure to continue to step 64 when incoming data is 
detected. 

When incoming data is received, the procedure continues 
to step 64, in which the server requests filter criteria from the 
client. In response to the server's request for filter criteria, 
the client determines the level of trust associated with the 
requesting server at step 66. At step 68, the client transmits 
profile data elements associated with the server's level of 
trust to the server. These profile data elements arc referred to 
as the server filter criteria. In a particular embodiment of the 
invention, the server discards the server filter criteria after 
filtering the received data. In an alternate embodiment of the 
invention, the server may store the server filter criteria for 
use with the next incoming data. In this alternate 
embodiment, the client may update the server with new 
server filter criteria each time the server filter criteria 
changes. 

At step 70 of FIG. 3, the incoming data is filtered on the 
server using the server filter criteria. Step 72 transmits the 
filtered data, if any, from the server to the client. At step 74, 
the data received by the client is filtered using the profile 
data elements associated with the client (referred to as the 
client filter criteria). The filtered data, if any, generated by 
the client is then processed at step 76. As discussed above, 
this processing may include displaying the filtered data to 
the user or notifying the user of the received data. If cither 
the filtering performed by the server at step 70 or by the 
client at step 74 eliminates all data, then the procedure 
terminates without notifying the user. 

Embodiments of the present invention execute the proce- 
dures described above with respect to FIGS. 2 and 3 



15 



20 



25 



35 



40 



45 



50 



55 



continually (e.g., in a background mode). Therefore, the 
client and server(s) may exchange filter criteria, filtered data, 
and other information while the client is executing other 
applications or procedures. 

FIG. 4 illustrates an embodiment of a profile data set 80 
for use with the present invention. In one embodiment of the 
invention, a separate profile data set 80 is provided for each 
client (or each user). Profile data set 80 includes a set of 
profile data elements 82 that are related to user-specific 
information (e.g., age, occupation, or marital status). Profile 
data set 80 also includes a set of profile data elements 84 that 
are related to one or more user roles. A user role can be, for 
example, "professor" or "Vice President of Engineering." 
Profile data elements 84 related to a user role identify 
characteristics or attributes associated with that role, rather 
than an individual person. Therefore, all users performing a 
particular role may use profile data elements 84 rather than 
or in addition to entering those attributes along with their 
user-specific information. Furthermore, the attributes asso- 
ciated with a particular role can be updated once rather than 
updating each user's specific information. If a particular user 
performs multiple roles, then that user's profile data set 80 
will contain profile data elements related to all of the roles 
performed by the user. 

Profile data set 80 further includes a set of profile data 
elements 86 that are related to one or more user classes. A 
user class can be, for example, "marketing" or "engineers." 
Profile data elements 86 related to a user class identify 
characteristics or attributes associated with a class of users. 
Therefore, all users that are members of a particular class 
can use profile data elements 86 rather than entering those 
attributes along with their user-specific information. 
Additionally, the attributes associated with a particular class 
can be updated once rather than updating each member's 
specific information. If a particular user is a member of 
multiple classes, then that user's profile data set 80 will 
contain profile data elements related to all of the classes of 
which the user is a member. Additionally, a particular user 
may override the value associated with an attribute associ- 
ated with a role or a class. For example, a role "Software 
Engineering Manager" may have an attribute "job level" 
with a value "grade 1." If a particular user performing the 
role of Software Engineering Manager has a job level "grade 
2," that user's profile data set will contain an entry for the 
"job level" — "grade 2" pair that overrides the value pro- 
vided by the role. Thus, the values associated with role or 
class attributes may operate as default values that can be 
changed by a user's profile data set. 

As shown in FIG. 4, profile data elements 84 related to 
user roles and profile data elements 86 related to user classes 
are stored within profile data set 80. In alternative embodi- 
ments of the invention, a pointer or similar mechanism is 
provided in profile data set 80 that identifies a centralized 
storage location for the profile data elements related to user 
roles or user classes. The use of profile data elements related 
to user roles and user classes is optional. In alternative 
embodiments of the invention, profile data set 80 may 
include only profile data elements 82 related to user-specific 
information. 

FIG. 5 illustrates exemplary profile data elements related 
to user-specific information (e.g., profile data elements 82 in 
FIG. 4). The data elements shown in FIG. 5 are arranged into 
a table format for purposes of illustration. However, the 
actual data elements may be stored in any configuration 
using any data structure. The data elements in FIG. 5 include 
several attribute-value pairs (i.e., a value associated with 
each attribute). Additionally, a privacy characteristic is asso- 
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dated with each attribute-value pair. For example, the 
attribute "name" has a value "John Doe" and an associated 
privacy characteristic "Public." Thus, the user's name is 
John Doe and the user has made their name public. Public 
attributes are provided to all servers (whether the server is 5 
considered trustworthy or untrustworthy). The employer 
attribute has a value "Acme Corp." and has an associated 
privacy characteristic "Semi-Private." A "Semi-Private" pri- 
vacy characteristic indicates that the a1 tribute is only pro- 
vided to trustworthy servers (i.e., not provided to untrust- J0 
worthy servers). Trustworthy servers may be those servers 
located inside a corporate firewall and untrustworthy servers 
may be those servers located outside the corporate firewall. 
A third privacy characteristic, "Private," indicates that the 
attribute is only provided to clients, and is not provided to 15 
any server, whether trusted or untrusted. The example of 
FIG. 5 contains three different levels of privacy (Public, 
Semi-Private, and Private). However, in alternate embodi- 
ments of the invention, any number of privacy levels may be 
provided. As discussed in greater detail below, the number 2Q 
of privacy levels does not necessarily equal the number of 
filtering stages. 

By using the profile data elements discussed above and 
assigning privacy characteristics to each attribute -value pair, 
the user is able to make an informed tradeoff between the ^ 
privacy of the profile data and the bandwidth and local 
storage requirements. For example, if the user has a strong 
privacy interest, then only a few of the attribute -value pairs 
may be assigned a "Public" privacy characteristic. In this 
example, less profile data is exposed to untrusted servers, so 30 
additional data is received and processed by the client. In 
another situation, if the user desires a reduction in bandwidth 
and local storage requirements, many of the attribute-value 
pairs may be assigned a "Public" privacy characteristic. In 
this situation, more profile data is exposed to untrusted 35 
servers, but less data is received and stored by the client. 

The privacy characteristics associated with a particular 
attribute -value pair can be determined by the user or the data 
provider. A default privacy characteristic may be provided 
for some or all of the attribute-value pairs. For example, a 40 
default privacy characteristic of "Private" may be associated 
with all attribute-value pairs to avoid exposing any private 
information about the user unless the user specifically 
changes the default setting. 

Embodiments of the invention allow users to further limit 45 
the distribution of attribute-value pairs to particular types of 
servers. For example, a user of a particular brand of com- 
puter may only want the "Model Number" attribute to be 
provided to servers associated with the manufacturer of the 
computer. Thus, the "Model Number" may have a privacy 50 
characteristic of "Public", but the attribute-value pair is only 
distributed to servers associated with the particular manu- 
facturer of the computer. The distribution of any attribute- 
value pair can be limited, regardless of the privacy charac- 
teristic. Additionally, a user may deactivate a particular 55 
attribute-value pair such that the attribute-value pair is not 
distributed to any server or client. The attribute-value pair 
remains deactivated until reactivated by the user. This deac- 
tivation provides a temporary way for a user to prevent 
filtering based on a particular attribute-value pair without 60 
permanently deleting the information from the profile data 
set. 

FIGS. 6Aand 6B illustrate exemplary server filter criteria 
and client filter criteria, respectively, generated from the 
profile data elements shown in FIG. 5. The server filter 65 
criteria shown in FIG. 6A contains two attribute -value pairs 
corresponding to the two "Public" entries shown in FIG. 5. 
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The server filter criteria shown in FIG. 6Adoes not include 
the privacy characteristics. The privacy characteristics are 
used to determine which servers or clients will receive a 
particular attribute-value pair. However, the privacy charac- 
teristics are not transmitted along with the filter criteria. 

Using the exemplary filter criteria shown in FIG. 6A, a 
server is able to filter incoming data. For example, if the 
server receives incoming data (such as an advertisement or 
news article) targeted to male computer users over the age 
of 40, the server filter will allow the data to pass to the next 
data filtering stage because the server filter criteria for John 
Doe identifies that John Doe is male. Although the next data 
filtering stage will reject the data because John Doc is not 
over 40, the server is unaware of John Doc's age and cannot 
filter the data based on that attribute. Using the example 
filter criteria shown in FIG. 6A, the server is only capable of 
filtering incoming data based on the user's name and gender. 
If the user changes the privacy characteristic associated with 
attribute "Age" to "Public," then the server's filter criteria 
will include the attribute-value pair "Age — 38". In this 
situation, the server will filter out the incoming data based 
on John Doe's age. 

FIG. 6B contains six attribute-value pairs corresponding 
to the "Semi-Private" and "Private" entries shown in FIG. 5. 
In this example, two filtering stages are used, but three levels 
of privacy characteristics are provided. Therefore, two of the 
privacy characteristic levels are combined into a single 
filtering stage. For this example, "Public" entries are pro- 
vided in the server filter criteria and "Semi-Private" and 
"Private" entries are provided in the client filter criteria. In 
an alternative embodiment, the "Public" and "Semi- Private" 
entries are provided in the server filter criteria and the 
"Private" entries are provided in the client filter criteria. 
Although FIG. 6B illustrates the client filter criteria sepa- 
rately from the profile data elements shown in FIG. 5, 
embodiments of the invention may read the client filter 
criteria directly from the profile data elements instead of 
generating a separate instance of the client filter criteria. 

FIGS. 6A and 6B illustrate server filter criteria and client 
filter criteria having distinct attributes; i.e., no shared 
attributes. Thus, the server filter criteria and the client filter 
criteria are completely different from one another. However, 
in other embodiments of the invention, one or more of the 
attributes may be contained in two or more filter criteria. For 
example, the attribute "Age" may be contained in both the 
server filter criteria and the client filter criteria such that both 
the server and the client perform data filtering using the 
"Age" attribute. However, the server filter criteria and the 
client filter criteria do not generally share all attributes. Any 
two filter criteria are "different" if at least one data clement 
is different between the two criteria (e.g., a different attribute 
or a different attribute value). 

FIG. 7 illustrates another embodiment of a multi-stage 
data filtering system. The embodiment of FIG. 7 represents 
a unified three-stage data filtering system (untrusted server, 
trusted server, and client). As mentioned above, the teach- 
ings of the present invention may be applied to data filtering 
systems having any number of data filtering stages. The 
components contained within the servers and the client in 
FIG. 7 are similar to those discussed above with reference to 
FIG. 1. Untrusted server 100 receives incoming data from a 
data source (not shown) and filters the incoming data using 
an untrusted server filter criteria. The filtered data, if any, is 
then communicated from untrusted server 100 to trusted 
server 102. Trusted server 102 filters the received data using 
a trusted server filter criteria. The filtered data, if any, is then 
communicated from trusted server 102 to client 104. Client 
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104 filters the received data using a client filter criteria to disk drive 142 is coupled to bus 130 and provides for the 

generate a final set of filtered data. The filtering process may long-term mass storage of information. Disk drive 142 may 

be terminated at any point if the output of a particular filter be used to store various profile data sets and other data 

removes all data. generated by and used by the data filtering system. A 

FIGS. 8A-8C illustrate exemplary filter criteria for use in 5 keyboard 144 and pointing device 148 are also coupled to 

the three-stage data filtering system shown in FIG. 7. FIGS. Dus 130 and provide mechanisms for entering information 

8A-8C use the exemplary profile data elements shown in and commands to the computer. A printer 146 is coupled to 

FIG. 5. FIG. 8A illustrates an untnisted server filter criteria bus 130 and * capable of creating a hard-copy of informa- 

(i.e., the attribute-value pairs having a privacy characteristic tion generated by or used by the computer. 

"Public"). FIG. 8B illustrates a trusted server filter criteria 10 FIG. 11 illustrates an embodiment of a computer-readable 

(i.e., the attribute-value pairs having a "Semi-Private" pri- medium 150 containing various sets of instructions, code 

vacy characteristic). FIG. 8C illustrates a client filter criteria sequences, configuration information, and other data used by 

(i.e., the attribute-value pairs having a privacy characteristic a computer or other processing device. The embodiment 

"Private"). illustrated in FIG. 11 is suitable for use with the data filtering 

FIG. 9 illustrates another embodiment of a multi-stage 15 system described above. The various information stored on 

data filtering system in which a client 126 receives data from medium 150 is used to perform various data filtering and 

multiple servers 110-124. A single profile data set is stored dala processing operations. Computer-readable medium 150 

in client 126. Client 126 distributes various attribute-value is also referred to as a processor-readable medium, 

pairs to the multiple servers based on the tnistworthbess of Computer-readable medium 150 can be any type of 

the server and the privacy characteristics associated with 20 magnetic, optical, or electrical storage medium including a 

each attribute-value pair. For example, untnisted servers 110 diskette, magnetic tape, CD-ROM, memory device, or other 

and 112 may receive an untnisted server filter criteria storage medium. 

containing only "Public" attribute-value pairs, and trusted Computer- readable medium 150 includes interface code 

server 120 receives a trusted server filter criteria containing 152 that controls the flow of information between various 

"Semi-Private" attribute-value pairs. Additionally, trusted 25 devices or components in a data filtering system. Interface 

server 124 may receive a trusted server filter criteria con- code 152 may control the transfer of information within a 

taining "Public" and "Semi-Private" attribute-value pairs. device (e.g., between the processor and a memory device), 

Untnisted server 112 may receive "Public" attribute-value or between an input/output port and a storage device, 

pairs, while the "Semi-Private" and "Private" attribute pairs Additionally, interface code 152 may control the transfer of 

arc filtered by client 126. Thus, client 126 may be filtering 30 information from one device to another (e.g., the transfer of 

"Private" attribute -value pairs for some incoming data and filtered data or profile data between a client and a server), 

filtering "Semi-Private" and "Private" attribute-value pairs Data filtering code 154 filters received data based on a 

for other incoming data. particular filter criteria, as discussed above. 

It is not necessary that data filtering occur at every device 35 Computer-readable medium 150 also includes a profile 

through which the data passes. For example, untnisted data set 156 used to filter data and generate filter criteria, 

servers 116 and 118 may receive "Public" attribute-value Profile data set 156 may include user-specific information, 

pairs, and the remaining "Semi-Private" and "Private" information related to user role(s), and/or information 

attribute-value pairs are filtered by client 126. In this related to user class(es). Filter criteria 158 is used by the data 

example, the filtered data from untnisted servers 116 and 118 ^ filtering procedures described above. Received data 160 

passes through trusted server 122 without any data filtering represents data that has been received by a particular device 

operation. for filtering. Received data 160 may be filtered data from 

FIG. 10 illustrates an embodiment of a computer system another device or may be unfiltered incoming data distrib- 

that can be used with the present invention (e.g., as a client uted by a third-party data source. Filtered data 162 repre- 

or a server). The various components shown in FIG. 10 are 4S sents the output of the data filtering process as applied to 

provided by way of example. Certain components of the received data 160. If the filtering process filters out (i.e., 

computer in FIG. 10 can be deleted from the data filtering removes) all received data 160, then filtered data 162 may be 

system for a particular implementation of the invention. The a null set. 

computer shown in FIG. 10 may be any type of computer Profile data generation code 164 typically resides on a 

including a general purpose computer. so client, and is used to generate profile data set 156. Profile 

FIG. 10 illustrates a system bus 130 to which various data generation code 164 may be executed by a user of the 

components are coupled. A processor 132 performs the client to generate or modify the various profile data 

processing tasks required by the computer. Processor 132 attributes, values, and privacy characteristics contained in 

may be any type of processing device capable of imple- profile data set 156. Computer-readable medium 150 also 

menting the steps necessary to perform the data filtering 55 includes code 166 for determining a level of trust associated 

operations discussed above. An input/output (I/O) device with a particular device (such as a server). Typically, this 

134 is coupled to bus 130 and provides a mechanism for code 166 is executed by a user of the client and may assign 

communicating with other devices coupled to the computer. a default level of trust to a particular device if a level of trust 

A read-only memory (ROM) 136 and a random access is not otherwise assigned. For example, a default level of 

memory (RAM) 138 are coupled to bus 130 and provide a 50 trust may be "untnisted," such that the device only receives 

storage mechanism for various data and information used by profile data having a privacy characteristic of "Public." 

the computer. Although ROM 136 and RAM 138 are shown Filtered data processing code 168 processes filtered data 

coupled to bus 130, in alternate embodiments, ROM 136 and 162. For example, data processing code 168 may display 

RAM 138 are coupled directly to processor 132 or coupled filtered data 162 to a user, notify a user of the received data, 

to a dedicated memory bus (not shown). 55 or communicate filtered data 162 to the next device (e.g., 

A video display 140 is coupled to bus 130 and displays transmit filtered data 162 from a server to a client). Filter 

various information and data to the user of the computer. A criteria generation code 170 generates filter criteria based on 
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information contained in profile data set 156 and the level of 
trust for a particular device as determined by code 166. 
Typically, filter generation code 170 is executed by a client, 
which generates a filter criteria for a particular device. The 
filter criteria contains the attributes and values from profile 5 
data set 156 that correspond to the level of trust associated 
with the particular device. For example, an un trusted server 
may only receive attributes and values having a privacy 
characteristic of "Public." Therefore, the filter criteria for an 
un trusted server will not contain attributes and values having 10 
a privacy characteristic of "Semi-Private" or "Private." 

Computer-readable medium 150 also includes informa- 
tion 172 regarding user role(s) and information 174 regard- 
ing user class(es). As discussed above, information relating 
to user roles and user classes identify characteristics or 15 
attributes associated with roles or classes, rather than an 
individual person. As shown in FIG. 11, information 172 
regarding user role(s) and information 174 regarding user 
class(es) may be stored separately from profile data set 156. 
In alternate embodiments, information regarding user role(s) 20 
and clashes) may be stored within profile data set 156. 

FIG. 11 illustrates an exemplary computer-readable 
medium 150 containing various sets of instructions, code 
sequences, and other information that can be used by a data 
filtering system. However, in particular data filtering 25 
devices, one or more of the items illustrated in FIG. 11 may 
not be required. For example, in a computer-readable 
medium for use with an untrusted server that relies on a 
client for its filter criteria 158, the computer-readable 
medium need not contain profile data set 156, profile data 30 
generation code 164, code 166 for determining level of trust, 
filter criteria generation code 170, or information 172 and 
174 regarding user role(s) and user clashes). In this 
example, the client maintains the profile data set, generates 
the filter criteria for the untrusted server, and communicates 35 
the filter criteria to the untrusted server. To maintain the 
privacy of the profile data set, the profile data set is typically 
stored only on the client. 

Thus, a multi-stage data filtering system has been 
described that does not compromise a user's privacy. The 
system provides a filtering system that distributes multiple 
profile data elements to two or more data filtering stages, in 
which each data filtering stage may be performed by a 
different device or system. ^ 

From the above description and drawings, it will be 
understood by those of ordinary skill in the art that the 
particular embodiments shown and described are for pur- 
poses of illustration only and are not intended to limit the 
scope of the invention. Those of ordinary skill in the art will SQ 
recognize that the invention may be embodied in other 
specific forms without departing from its spirit or essential 
characteristics. References to details of particular embodi- 
ments are not intended to limit the scope of the claims. 

What is claimed is: S5 
1. A method of filtering data, the method comprising: 
providing from a trusted second device, a first filter 
criteria to an untrusted first device, the first filter criteria 
being non-private filter criteria and determined at least 
in part on trustworthiness of the untrusted first device, qq 
wherein the untrusted first device uses the first filter 
criteria to filter data received by the untrusted first 
device and generate a first set of filtered data; 
the trusted second device receiving the first set of filtered 

data from the untrusted first device; and 65 
filtering by the trusted second device the first set of 
filtered data based on a second filter criteria, the second 
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filter criteria determined at least in part on trustworthi- 
ness of the trusted second device, wherein the filtering 
of the first set of filtered data generates a second set of 
filtered data, wherein the second filter criteria is dif- 
ferent from the first filter criteria. 

2. The method of claim 1 wherein the first filter criteria 
and the second filter criteria contain different filter charac- 
teristics. 

3. The method of claim 1 wherein the first filter criteria 
and the second filter criteria are included in a profile data set. 

4. The method of claim 3 wherein the first filter criteria 
contains public profile data. 

5. The method of claim 3 wherein the second filter criteria 
contains private profile data. 

6. The method of claim 3 wherein the profile data set 
contains at least one data element associated with user- 
specific information. 

7. The method of claim 3 wherein the profile data set 
contains at least one data element associated with a user 
class. 

8. The method of claim 3 wherein the profile data set 
contains at least one data element associated with a user role. 

9. A method of filtering data, the method comprising the 
steps of: 

filtering data in an untrusted first data filtering device 
based on a first filter criteria from a trusted second 
device, determined at least in part on trustworthiness of 
the first untrusted data filtering device so that private 
filter criteria is not provided to the untrusted first data 
filtering device, the filtering generating a first set of 
filtered data; and 

providing at least a portion of the first set of filtered data 
to a trusted second data filtering device to filler the first 
set of filtered data based on a second filter criteria. 

10. The method of claim 9 wherein the step of filtering at 
least a portion of the first set of filtered data in the trusted 
second data device generates a second set of filtered data. 

11. The method of claim 9 wherein the first filter criteria 
and the second filter criteria contain different filter charac- 
teristics. 

12. The method of claim 9 wherein the first filter criteria 
and the second filter criteria are included in a profile data set. 

13. The method of claim 12, in which the first data 
filtering device is untrusted such that the first filter criteria 
contains public profile data. 

14. The method of claim 12 wherein the second filter 
criteria contains private profile data. 

15. The method of claim 12 wherein the profile data set 
contains at least one data element associated with user- 
specific information. 

16. The method of claim 12 wherein the profile data set 
contains at least one data element associated with a user role. 

17. The method of claim 12 wherein the profile data set 
contains at least one data element associated with a user role. 

18. A method of filtering data by an untrusted filtering 
device, the method comprising: 

receiving a first filter criteria commensurate with the 
trustworthiness of the untrusted filtering device from a 
trusted data filtering device, the filtering criteria based 
at least in part according to trustworthiness of the 
untrusted filtering device and private filter criteria is not 
provided to the untrusted filtering device; 

receiving incoming data from a data source; 

filtering the incoming data using the first filter criteria to 
generate a first set of filtered data; and 

providing the first set of filtered data to the trusted data 
filtering device, 
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wherein the trusted data filtering device uses a second 
filter criteria based at least in part on trustworthiness of 
the trusted data filtering device to filter the first set of 
filtered data. 

19. The method of claim 18 wherein the first filter criteria 5 
and the second filter criteria contain different filter charac- 
teristics. 

20. The method of claim 18 wherein the first filter criteria 
and the second filter criteria are included in a profile data set. 

21. The method of claim 20 wherein the second filter to 
criteria contains private profile data. 

22. The method of claim 21 wherein the method is 
performed by an untrusted filtering device. 

23. A computer software product including a medium 
readable by a processor, the medium having stored thereon 15 
a sequence of instructions which, when executed by the 
processor of a trusted receiving device, cause the processor 
to: 

provide to an untrusted first device from the trusted 
receiving device, a first filter criteria determined at least 20 
in part on trustworthiness of the untrusted first device, 
wherein the untrusted first device uses the first filter 
criteria to filter data received by the untrusted first 
device and generate a first set of filtered data; 

the trusted receiving device receive the first set of filtered 25 
data from the untrusted first device; and 

filter the first set of filtered data based on a second filter 
criteria to generate a second set of filtered data, the 
second filter criteria determined at least in part on 3Q 
trustworthiness of the trusted receiving device, wherein 
the second filter criteria is different from the first filter 
criteria, and wherein the filter criteria of the untrusted 
first device is non-private filter criteria. 

24. The computer software product of claim 23 wherein 35 
the first filter criteria and the second filter criteria are 
included in a profile data set. 

25. The computer software product of claim 24 wherein 
the first filter criteria contains public profile data. 

26. The computer software product of claim 24 wherein ^ 
the second filter criteria contains private profile data. 

27. A computer software product including a medium 
readable by a processor of an untrusted receiving device, the 
medium having stored thereon a sequence of instructions 
which, when executed by the processor, cause the processor 45 
to: 

receive a first filter criteria determined at least in part on 
trustworthiness of the untrusted receiving device from 
a trusted data filtering device wherein the first filter 
criteria is non-private filter criteria; 50 

receive incoming data from a data source; 

filter the incoming data using the received first filter 
criteria to generate a first set of filtered data; and 

provide the first set of filtered data to the data filtering 
device, wherein the data filtering device uses a second 
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filter criteria determined at least in part on trustworthi- 
ness of the trusted data filtering device to filter the first 
set of filtered data. 

28. The computer software product of claim 27 wherein 
the first filter criteria and the second filter criteria contain 
different filter characteristics. 

29. The computer software product of claim 27 wherein 
the first filter criteria and the second filter criteria are 
included in a profile data set. 

30. The computer software product of claim 29 wherein 
the first filter criteria contains public profile data. 

31. The computer software product of claim 29 wherein 
the second filter criteria contains private profile data. 

32. A trusted data filtering apparatus comprising: 

a data communication mechanism configured to provide a 
non-private filter criteria to an untrusted filtering 
device, wherein the untrusted filtering device uses the 
non-private filter criteria to generate a first set of 
filtered data, and wherein the data communication 
mechanism is further configured to receive the first set 
of filtered data from the untrusted filtering device; and 

a data filter configured to filter the first set of filtered data 
based on a private filter criteria, wherein the filtering of 
the first set of filtered data generates a second set of 
filtered data, 

wherein filtering criteria is configured at least in part 
according to trustworthiness of the untrusted filtering 
device so that private filter criteria is not provided to 
untrustworthy filtering devices. 

33. The data filtering apparatus of claim 32 wherein the 
first filter criteria and the second filter criteria are included 
in a profile data set. 

34. An untrusted data filtering apparatus comprising: 

a data receiving mechanism configured to receive a first 
filter criteria from a trusted device and configured to 
receive incoming data from a data source; 

a data filter configured to filter the incoming data using the 
first filter criteria and generate a first set of filtered data, 
the first filler criteria determined at least in part on the 
trustworthiness of the untrusted data filtering apparatus 
so that the untrusted data filtering apparatus does not 
receive private filter criteria; and 

a data transmitting mechanism configured to transmit the 
first set of filtered data to the trusted device, wherein 
the trusted device uses a second filter criteria commen- 
surate with a trustworthiness of the trusted device to 
filter the first set of filtered data. 

35. The data filtering apparatus of claim 34 wherein the 
first filter criteria and the second filter criteria are included 
in a profile data set 

36. The method of claim 1 further including determining 
the trustworthiness of the trusted device. 

***** 
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